- 26 Jun, 2006 5 commits
-
-
unknown authored
into mysql.com:/home/mydev/mysql-5.0-bug16986-main sql/sql_table.cc: Auto merged
-
unknown authored
into mysql.com:/home/mydev/mysql-5.0-bug16986-main sql/mysql_priv.h: Auto merged sql/sql_base.cc: Auto merged sql/sql_parse.cc: Auto merged
-
unknown authored
Addendum fixes after changing the condition variable for the global read lock. The stress test suite revealed some deadlocks. Some were related to the new condition variable (COND_global_read_lock) and some were general problems with the global read lock. It is now necessary to signal COND_global_read_lock whenever COND_refresh is signalled. We need to wait for the release of a global read lock if one is set before every operation that requires a write lock. But we must not wait if we have locked tables by LOCK TABLES. After setting a global read lock a thread waits until all write locks are released. mysql-test/r/lock_multi.result: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Added test results. mysql-test/t/lock_multi.test: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Added tests for possible deadlocks that did not occur with the stress test suite. mysys/thr_lock.c: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Added a protection against an infinite loop that occurs with the test case for Bug #20662. sql/lock.cc: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Signal COND_global_read_lock whenever COND_refresh is signalled by using the new function broadcast_refresh(). Added the definition of a new function that signals COND_global_read_lock whenever COND_refresh is signalled. sql/mysql_priv.h: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Added a declaration for a new function that signals COND_global_read_lock whenever COND_refresh is signalled. sql/sql_base.cc: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Signal COND_global_read_lock whenever COND_refresh is signalled by using the new function broadcast_refresh(). sql/sql_handler.cc: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Signal COND_global_read_lock whenever COND_refresh is signalled by using the new function broadcast_refresh(). sql/sql_insert.cc: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Removed global read lock handling from inside of INSERT DELAYED. It is handled on a higher level now. sql/sql_parse.cc: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Wait for the release of a global read lock if one is set before every operation that requires a write lock. But don't wait if locked tables exist already. sql/sql_table.cc: Bug#16986 - Deadlock condition with MyISAM tables Addendum fixes after changing the condition variable for the global read lock. Removed global read lock handling from inside of CREATE TABLE. It is handled on a higher level now. Signal COND_global_read_lock whenever COND_refresh is signalled by using the new function broadcast_refresh().
-
unknown authored
into mysql.com:/home/tnurnberg/mysql-5.0-maint-18462 mysql-test/r/mysqldump.result: Auto merged mysql-test/t/mysqldump.test: Auto merged client/mysqldump.c: SCCS merged
-
unknown authored
into mysql.com:/data0/bk/mysql-5.0-maint sql/sp_head.cc: Auto merged sql/table.cc: Auto merged
-
- 24 Jun, 2006 2 commits
-
-
unknown authored
into mysql.com:/data0/knielsen/tmp-5.0
-
unknown authored
Sometimes the helper connection (that is watching for the main connection to time out) would itself time out first, causing the test to fail. mysql-test/t/wait_timeout.test: Increase connection timeout in connection wait_con so we will not loose the connection that is watching for the real wait_timeout to trigger.
-
- 23 Jun, 2006 7 commits
-
-
unknown authored
into mysql.com:/mnt/storeage/mysql-5.0-maint_bug20616
-
unknown authored
sql/sql_table.cc: Check for FN_DEVCHAR in the table name just before file creation. This allows for temporary tables to contain FN_DEVCHAR in the name. sql/table.cc: Removed the check for FN_DEVCHAR is done at this level because it prevents Windows from creating any table with FN_DEVCHAR in the name.
-
unknown authored
After merge fix mysql-test/r/key.result: After merge fix
-
unknown authored
-
unknown authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql sql/sql_parse.cc: Auto merged
-
unknown authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql mysql-test/r/key.result: Auto merged mysql-test/t/key.test: Auto merged sql/table.cc: Auto merged support-files/mysql.spec.sh: Auto merged
-
unknown authored
An UNIQUE KEY consisting of NOT NULL columns was displayed as PRIMARY KEY in "DESC t1". According to the code, that was intentional behaviour for some reasons unknown to me. This code was written before bitkeeper time, so I cannot check who and why made this. After discussing on dev-public, a decision was made to remove this code mysql-test/r/key.result: Adding test case. mysql-test/t/key.test: Adding test case. sql/table.cc: Removing old wrong code
-
- 22 Jun, 2006 13 commits
-
-
unknown authored
Disable the simplistic auto dependency scan for test/bench (bug#20078) support-files/mysql.spec.sh: Disable the simplistic auto dependency scan for test/bench (bug#20078)
-
unknown authored
into mysql.com:/home/tnurnberg/mysql-5.0-maint-19409
-
unknown authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
unknown authored
into clam.ndb.mysql.com:/space/pekka/ndb/version/my50-bug18781 ndb/src/kernel/blocks/dbdih/DbdihMain.cpp: Auto merged ndb/src/ndbapi/ndberror.c: Auto merged
-
unknown authored
- The setting of "ENV{'TZ'}" doesn't affect the timezone used by MySQL Server on Windows. - Explicitly set timezone in test cases before doing UTC/localtime conversions so tests produce deterministic results mysql-test/r/func_timestamp.result: Update test results mysql-test/r/type_timestamp.result: Update test results mysql-test/t/func_timestamp.test: Specifically set timezone to make tests that do localtime/UTC conversions deterministic mysql-test/t/type_timestamp.test: Specifically set timezone to make tests that do localtime/UTC conversions deterministic
-
unknown authored
- The setting of "ENV{'TZ'}" doesn't affect the timezone used by MySQL Server on Windows. - Explicitly set timezone to "+03:00" in test case before doing the calculatiosn to check that there is three hours difference between utc and local time. (Magnus' fix) mysql-test/r/func_time.result: Update test results mysql-test/t/func_time.test: Set timezone to GMT-3, to make it possible to use "interval 3 hour"
-
unknown authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug15811
-
unknown authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
unknown authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug15811
-
unknown authored
with PREPARE fails with weird error". More generally, re-executing a stored procedure with a complex SP cursor query could lead to a crash. The cause of the problem was that SP cursor queries were not optimized properly at first execution: their parse tree belongs to sp_instr_cpush, not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the cursor was declared, not when it was opened. This led to loss of optimization transformations performed at first execution, as sp_instr_copen saw that the query is already "EXECUTED" and therefore either not ran first-execution related blocks or wrongly rolled back the transformations caused by first-execution code. The fix is to update the state of the parsed tree only when the tree is executed, as opposed to when the instruction containing the tree is executed. Assignment if i->state is moved to reset_lex_and_exec_core. mysql-test/r/sp.result: Test results fixed (Bug#15217) mysql-test/t/sp.test: Add a test case for Bug#15217 sql/sp_head.cc: Move assignment of stmt_arena->state to reset_lex_and_exec_core
-
unknown authored
The problem was in redundant calls to strlen() in string functions, where we may then return after checking only the small number of characters. No test case is provided since it's a performance fix. strings/ctype-mb.c: Do not use strlen() where arbitrary horizon of at least CHARSET_INFO::mbmaxlen character is sufficient.
-
unknown authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
unknown authored
into zippy.(none):/home/cmiller/work/mysql/mysql-5.0__bug19904
-
- 21 Jun, 2006 13 commits
-
-
unknown authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
unknown authored
into a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0
-
unknown authored
mysql-test/r/ctype_utf8.result: Auto merged mysql-test/t/ctype_utf8.test: Auto merged
-
unknown authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
unknown authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
unknown authored
This bug in Field_string::cmp resulted in a wrong comparison with keys in partial indexes over multi-byte character fields. Given field a is declared as a varchar(16) collate utf8_unicode_ci INDEX(a(4)) gives us an example of such an index. Wrong key comparisons could lead to wrong result sets if the selected query execution plan used a range scan by a partial index over a utf8 character field. This also caused wrong results in many other cases. mysql-test/t/ctype_utf8.test: Added test cases for bug #14896. mysql-test/r/ctype_utf8.result: Added test cases for bug #14896. sql/field.cc: Fixed bug #14896. This bug in Field_string::cmp resulted in a wrong comparison with keys in partial indexes over multi-byte character fields. Given field a is declared as a varchar(16) collate utf8_unicode_ci INDEX(a(4)) gives us an example of such an index. Wrong key comparisons could lead to wrong result sets if the selected query execution plan used a range scan by a partial index over a utf8 character field. This also caused wrong results in many other cases.
-
unknown authored
into mysql.com:/home/bk/fix-mysql-5.0
-
unknown authored
into a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0
-
bk://localhost:5559unknown authored
into a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0
-
unknown authored
include/my_libwrap.h: Changed includes to the header file. mysys/my_libwrap.c: Added comment and .c file now takes needed includes from the corresponding .h file. sql/mysqld.cc: Include this block from my_libwra.h now. Moved two variables out of the otherwise same block.
-
unknown authored
into zippy.(none):/home/cmiller/work/mysql/mysql-5.0-maint
-
unknown authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-5.0 mysql-test/r/myisam.result: Auto merged mysql-test/t/myisam.test: Auto merged sql/opt_sum.cc: Auto merged mysql-test/mysql-test-run.sh: Auto merged
-
unknown authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
-