Commit graph

9492 commits

Author SHA1 Message Date
istruewing@chilla.local
35c94b6e2d Merge bk-internal.mysql.com:/home/bk/mysql-5.0-engines
into  chilla.local:/home/mydev/mysql-5.0-bug8283
2006-10-11 17:57:47 +02:00
evgen@moonbone.local
ea8a646dc0 Bug#22138: Unhandled NULL caused server crash
The Cached_item_decimal::cmp() method wasn't checking for null pointer
returned from the val_decimal() of the item being cached.
This leads to server crash.

The Cached_item_decimal::cmp() method now check for null values.
2006-10-11 19:44:12 +04:00
svoj@mysql.com/april.(none)
62b2044279 BUG#22562 - REPAIR TABLE .. USE_FRM causes server crash on Windows and server
hangs on Linux

If REPAIR TABLE ... USE_FRM is issued for table that is located in different
than default database server crash could happen.

In reopen_name_locked_table take database name from table_list (user specified
or default database) instead of from thd (default database).

Affects 4.1 only.
2006-10-11 20:34:20 +05:00
jonas@perch.ndb.mysql.com
ca4e9be98f Merge perch.ndb.mysql.com:/home/jonas/src/mysql-5.0
into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb
2006-10-11 14:02:43 +02:00
kroki/tomash@moonlight.intranet
4db25e06d8 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354
2006-10-10 20:58:40 +04:00
kroki/tomash@moonlight.intranet
7c0e002f9e Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354
2006-10-10 18:11:10 +04:00
kroki/tomash@moonlight.intranet
b2c6ff7ab1 Fix after manial merge. 2006-10-10 17:51:12 +04:00
kroki/tomash@moonlight.intranet
0d457976ea Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug21354
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354
2006-10-10 17:18:36 +04:00
kroki/tomash@moonlight.intranet
fbf6507cf7 BUG#21354: (COUNT(*) = 1) not working in SELECT inside prepared
statement.

The problem was that during statement re-execution if the result was
empty the old result could be returned for group functions.

The solution is to implement proper cleanup() method in group
functions.
2006-10-10 17:08:47 +04:00
kroki/tomash@moonlight.intranet
ee9afdbc13 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug19111
2006-10-10 16:44:59 +04:00
kroki/tomash@moonlight.intranet
4a28f8f1a0 Bug#19111: TRIGGERs selecting from a VIEW on the firing base table fail.
In a trigger or a function used in a statement it is possible to do
SELECT from a table being modified by the statement.  However,
encapsulation of such SELECT into a view and selecting from a view
instead of direct SELECT was not possible.

This happened because tables used by views (which in their turn
were used from functions/triggers) were not excluded from checks
in unique_table() routine as it happens for the rest of tables
added to the statement table list for prelocking.

With this fix we ignore all such tables in unique_table(), thus
providing consistency: inside a trigger or a functions SELECT from
a view may be used where plain SELECT is allowed.  Modification of
the same table from function or trigger is still disallowed.  Also,
this patch doesn't affect the case where SELECT from the table being
modified is done outside of function of trigger, such SELECTs are
still disallowed (this limitation and visibility problem when function
select from a table being modified are subjects of bug 21326).  See
also bug 22427.
2006-10-10 13:44:04 +04:00
kostja@bodhi.local
b262a6a4b8 Merge bodhi.local:/opt/local/work/mysql-5.0-root
into  bodhi.local:/opt/local/work/mysql-5.0-runtime
2006-10-09 18:04:09 -07:00
istruewing@chilla.local
014c1c885e Bug#8283 - OPTIMIZE TABLE causes data loss
After merge fix. MyISAM version 10.
2006-10-09 22:16:22 +02:00
istruewing@chilla.local
c299de14ee Merge chilla.local:/home/mydev/mysql-4.1-bug8283-one
into  chilla.local:/home/mydev/mysql-5.0-bug8283
2006-10-09 20:03:12 +02:00
istruewing@chilla.local
1daa6a710d Merge chilla.local:/home/mydev/mysql-4.1-bug8283
into  chilla.local:/home/mydev/mysql-4.1-bug8283-one
2006-10-09 19:40:16 +02:00
istruewing@chilla.local
5f08a83186 Bug#8283 - OPTIMIZE TABLE causes data loss
OPTIMIZE TABLE with myisam_repair_threads > 1 performs a non-quick 
parallel repair. This means that it does not only rebuild all 
indexes, but also the data file.

Non-quick parallel repair works so that there is one thread per 
index. The first of the threads rebuilds also the new data file.

The problem was that all threads shared the read io cache on the
old data file. If there were holes (deleted records) in the table,
the first thread skipped them, writing only contiguous, non-deleted
records to the new data file. Then it built the new index so that
its entries pointed to the correct record positions. But the other
threads didn't know the new record positions, but put the positions
from the old data file into the index.

The new design is so that there is a shared io cache which is filled
by the first thread (the data file writer) with the new contiguous
records and read by the other threads. Now they know the new record
positions.

Another problem was that for the parallel repair of compressed
tables a common bit_buff and rec_buff was used. I changed it so
that thread specific buffers are used for parallel repair.

A similar problem existed for checksum calculation. I made this
multi-thread safe too.
2006-10-09 19:26:55 +02:00
malff/marcsql@weblab.(none)
6e809b249e Bug#21462 (Stored procedures with no arguments require parenthesis)
The syntax of the CALL statement, to invoke a stored procedure, has been
changed to make the use of parenthesis optional in the argument list.
With this change, "CALL p;" is equivalent to "CALL p();".

While the SQL spec does not explicitely mandate this syntax, supporting it
is needed for practical reasons, for integration with JDBC / ODBC connectors.

Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1
but are now reported by Bison 2.2, have been fixed.

The warning found were:
bison -y -p MYSQL  -d --debug --verbose sql_yacc.yy
sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared
sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared
sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared
sql_yacc.yy:5169.11-5174.11: warning: unused value: $2
sql_yacc.yy:5208.11-5220.11: warning: unused value: $5
sql_yacc.yy:5221.11-5234.11: warning: unused value: $5
conflicts: 249 shift/reduce

"unused value: $2" correspond to the $$=$1 assignment in the 1st {} block
in table_ref -> join_table {} {},
which does not procude a result ($$) for the rule but an intermediate $2
value for the action instead.
"unused value: $5" are similar, with $$ assignments in {} actions blocks
which are not for the final reduce.
2006-10-09 09:59:02 -07:00
gkodinov/kgeorge@macbook.local
5367793e8b Merge bk-internal:/home/bk/mysql-5.0-opt
into  macbook.local:/Users/kgeorge/mysql/work/B22781-5.0-opt
2006-10-09 19:53:07 +04:00
gkodinov/kgeorge@macbook.local
13633864bb Bug : SQL_BIG_RESULT fails to influence sort plan
Currently SQL_BIG_RESULT is checked only at compile time.
 However, additional optimizations may take place after
 this check that change the sort method from 'filesort'
 to sorting via index. As a result the actual plan
 executed is not the one specified by the SQL_BIG_RESULT
 hint. Similarly, there is no such test when executing
 EXPLAIN, resulting in incorrect output.
 The patch corrects the problem by testing for
 SQL_BIG_RESULT both during the explain and execution
 phases.
2006-10-09 19:51:41 +04:00
svoj@may.pils.ru
8cfef42f72 Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-5.0
into  may.pils.ru:/home/svoj/devel/bk/mysql-5.0-engines
2006-10-08 15:14:53 +05:00
svoj@may.pils.ru
b7f016dbd3 Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-4.1
into  may.pils.ru:/home/svoj/devel/bk/mysql-4.1-engines
2006-10-08 15:11:17 +05:00
svoj@mysql.com/april.(none)
60ba9f2b63 Merge mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-4.1-engines
into  mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.0-engines
2006-10-06 14:49:21 +05:00
svoj@mysql.com/april.(none)
6a1a765b5d Per discussion with pekka removed non-deterministic test case for bug#21381. 2006-10-06 14:47:58 +05:00
svoj@mysql.com/april.(none)
94040c54b3 Merge mysql.com:/home/svoj/devel/mysql/BUG10974/mysql-4.1-engines
into  mysql.com:/home/svoj/devel/mysql/BUG10974/mysql-5.0-engines
2006-10-06 11:01:39 +05:00
svoj@mysql.com/april.(none)
c67aa031d6 Addition to fix for bug#10974. Fixed spelling. 2006-10-06 10:54:47 +05:00
svoj@mysql.com/april.(none)
d41340516f Merge mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-4.1-engines
into  mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.0-engines
2006-10-05 19:02:29 +05:00
svoj@mysql.com/april.(none)
16c13a588f Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-4.1-engines
into  mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-4.1-engines
2006-10-05 18:56:10 +05:00
svoj@mysql.com/april.(none)
b141a7c1b9 BUG#21381 - Engine not notified about multi-table UPDATE IGNORE
Though this is not storage engine specific problem, I was able to
repeat this problem with BDB and NDB engines only. That was the
reason to add a test case into ndb_update.test. As a result
different bad things could happen.

BDB has removed duplicate rows which is not expected.
NDB returns an error.

For multi table update notify storage engine about UPDATE IGNORE
as it is done in single table UPDATE.
2006-10-05 18:23:53 +05:00
gluh@mysql.com/gluh.(none)
4f553f1d5f Merge mysql.com:/home/gluh/MySQL/Merge/4.1
into  mysql.com:/home/gluh/MySQL/Merge/4.1-kt
2006-10-05 16:38:21 +05:00
gluh@mysql.com/gluh.(none)
90116d2575 Merge mysql.com:/home/gluh/MySQL/Merge/5.0
into  mysql.com:/home/gluh/MySQL/Merge/5.0-kt
2006-10-05 13:41:58 +05:00
msvensson@neptunus.(none)
225b3e480b Merge bk-internal:/home/bk/mysql-5.0
into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-10-03 20:28:59 +02:00
anozdrin/alik@alik.
d238bd6755 Patch for BUG#15934: im_daemon_life_cycle fails sporadically.
The problem was a race condition in a test case.

The fix eliminates the race condition by explicit
wait on UNIX socket to start accepting connections.

The patch affects only test suite (i.e. does not touch
server codebase).
2006-10-03 18:42:59 +04:00
kroki/tomash@moonlight.intranet
995ac34a24 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726-fix
2006-10-03 17:21:28 +04:00
kroki/tomash@moonlight.intranet
31a206e877 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726-fix
2006-10-03 17:13:30 +04:00
msvensson@neptunus.(none)
4f46f3bde7 Merge bk-internal:/home/bk/mysql-5.0-runtime
into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-10-03 14:26:11 +02:00
msvensson@neptunus.(none)
3f8edc3706 Merge bk-internal:/home/bk/mysql-5.0-rpl
into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-10-03 14:24:43 +02:00
msvensson@neptunus.(none)
035b54049e Merge bk-internal:/home/bk/mysql-4.1-runtime
into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint
2006-10-03 12:55:33 +02:00
kroki/tomash@moonlight.intranet
8798b462b5 Fix for the patch for bug#21726: Incorrect result with multiple
invocations of LAST_INSERT_ID.

Reding of LAST_INSERT_ID inside stored function wasn't noted by caller,
and no LAST_INSERT_ID_EVENT was issued for binary log.

The solution is to add THD::last_insert_id_used_bin_log, which is much
like THD::last_insert_id_used, but is reset only for upper-level
statements.  This new variable is used to issue LAST_INSERT_ID_EVENT.
2006-10-03 13:38:16 +04:00
msvensson@neptunus.(none)
cc0f26c83f Merge bk-internal:/home/bk/mysql-4.1-rpl
into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint
2006-10-03 11:20:37 +02:00
msvensson@neptunus.(none)
ffeaf3eb85 Merge neptunus.(none):/home/msvensson/mysql/mysql-4.1
into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint
2006-10-03 11:19:00 +02:00
msvensson@shellback.(none)
b08195785c Merge bk-internal:/home/bk/mysql-5.0-maint
into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-10-03 09:03:28 +02:00
bar@mysql.com/bar.intranet.mysql.r18.ru
72ad606ece Merge mysql.com:/usr/home/bar/mysql-4.1.b8663
into  mysql.com:/usr/home/bar/mysql-4.1-rpl
2006-10-03 11:53:01 +05:00
dlenev@mockturtle.local
c30b6eafac Merge bk-internal.mysql.com:/home/bk/mysql-4.1
into  mockturtle.local:/home/dlenev/src/mysql-4.1-rt-merge
2006-10-03 08:19:06 +04:00
ramil/ram@mysql.com/myoffice.izhnet.ru
f2a3f1a679 Merge rkalimullin@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  mysql.com:/usr/home/ram/work/bug22271/my50-bug22271
2006-10-03 09:00:03 +05:00
msvensson@shellback.(none)
3bed246481 Merge shellback.(none):/home/msvensson/mysql/mysql-5.0
into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-10-03 01:01:06 +02:00
dlenev@mockturtle.local
8eb4401c59 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge
2006-10-02 22:53:10 +04:00
kroki/tomash@moonlight.intranet
f732270e5b Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21081
2006-10-02 18:01:04 +04:00
kroki/tomash@moonlight.intranet
8f3f277642 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726
2006-10-02 17:00:39 +04:00
lars/lthalmann@mysql.com/dl145h.mysql.com
a8e845a6d2 Merge mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl
into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
2006-10-02 14:19:51 +02:00
msvensson@neptunus.(none)
d5ad8ff4a2 Remove faulty merge 2006-10-02 14:05:36 +02:00