- 24 Oct, 2008 5 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
mysql-test/r/partition_not_windows.result: Update warning number due to new errors appearing earlier in the list. mysql-test/r/partition_symlink.result: Update warning number due to new errors appearing earlier in the list. mysql-test/r/symlink.result: Update warning number due to new errors appearing earlier in the list.
-
Ramil Kalimullin authored
Problem: mysqld doesn't detect that enum data must be reinserted performing 'ALTER TABLE' in some cases. Fix: reinsert data altering an enum field if enum values are changed. mysql-test/r/alter_table.result: Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1 - test result. mysql-test/t/alter_table.test: Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1 - test case. sql/field.cc: Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1 - Field_enum::is_equal() introduced, which is called to detect that a field is changing by 'ALTER TABLE'. sql/field.h: Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1 - Field_enum::is_equal() introduced, which is called to detect that a field is changing by 'ALTER TABLE'.
-
Sergey Petrunia authored
-
Sergey Petrunia authored
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out that HAVING is always FALSE re-committing to put the fix into 5.0 and 5.1 mysql-test/r/group_by.result: BUG#38072: Wrong result: HAVING not observed in a query with aggregate - Testcase mysql-test/t/group_by.test: BUG#38072: Wrong result: HAVING not observed in a query with aggregate - Testcase sql/sql_select.h: BUG#38072: Wrong result: HAVING not observed in a query with aggregate - Make send_row_on_empty_set() return FALSE when simplify_cond() has found out that HAVING is always FALSE
-
- 23 Oct, 2008 8 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Vladislav Vaintroub authored
Visual Studio 2008 Express edition does not include message compiler mc.exe It is not possible to build MySQL server if only VC2008 Express is installed, because we use mc.exe to generate event log messages. This patch removes the mc.exe dependency. Generated files message.h, message.rc and MSG00001.bin are checked into source code repository. Instructions on how to add or change messages are added to messages.mc
-
- 22 Oct, 2008 2 commits
-
-
Sven Sandberg authored
-
Sven Sandberg authored
Added test case to check the default value of @@binlog_format. mysql-test/t/binlog_format_basic.test: Added test case to verify the default binlog_format: it should be STATEMENT in 5.1 and MIXED in 6.0.
-
- 21 Oct, 2008 11 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
mysql-test/r/xa.result: Update test case result. mysql-test/t/xa.test: Drop table used for test.
-
Davi Arnaut authored
-
Davi Arnaut authored
The problem was that the server did not robustly handle a unilateral roll back issued by the Resource Manager (RM) due to a resource deadlock within the transaction branch. By not acknowledging the roll back, the server (TM) would eventually corrupt the XA transaction state and crash. The solution is to mark the transaction as rollback-only if the RM indicates that it rolled back its branch of the transaction. mysql-test/r/xa.result: Add test case result for Bug#28323 mysql-test/t/xa.test: Add test case for Bug#28323 sql/handler.cc: Reset XID only at the end of the global transaction. sql/share/errmsg.txt: Add new error codes. sql/sql_class.h: Remember the error reported by the Resource Manager. sql/sql_parse.cc: Rollback the transaction if the Resource Manager reported a error and rolled back its branch of the transaction.
-
Davi Arnaut authored
The problem was that the server did not robustly handle a unilateral roll back issued by the Resource Manager (RM) due to a resource deadlock within the transaction branch. By not acknowledging the roll back, the server (TM) would eventually corrupt the XA transaction state and crash. The solution is to mark the transaction as rollback-only if the RM indicates that it rolled back its branch of the transaction. mysql-test/r/xa.result: Add test case result for Bug#28323 mysql-test/t/xa.test: Add test case for Bug#28323 sql/handler.cc: Reset XID only at the end of the global transaction. sql/share/errmsg.txt: Add new error codes. sql/sql_class.h: Remember the error reported by the Resource Manager. sql/sql_parse.cc: Rollback the transaction if the Resource Manager reported a error and rolled back its branch of the transaction.
-
unknown authored
-
Kristofer Pettersson authored
Debug builds of MySQL 5.1, 6.0 with Sun Studio 12 broke because of use of gcc specific feature. The fix is to replace __FUNCTION__ with the corresponding character string
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
- 20 Oct, 2008 5 commits
-
-
Patrick Crews authored
-
Patrick Crews authored
Fixed .test file, re-recorded .result file Ensured reset of system variables at the end of subtests.
-
Kristofer Pettersson authored
-
Georgi Kodinov authored
-
Kristofer Pettersson authored
-
- 17 Oct, 2008 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 16 Oct, 2008 5 commits
-
-
Serge Kozlov authored
-
Gleb Shchepa authored
-
Gleb Shchepa authored
Server crashed during a sort order optimization of a dependent subquery: SELECT (SELECT t1.a FROM t1, t2 WHERE t1.a = t2.b AND t2.a = t3.c ORDER BY t1.a) FROM t3; Bitmap of tables, that the reference to outer table column uses, in addition to the regular table bit has the OUTER_REF_TABLE_BIT bit set. The only_eq_ref_tables function traverses this map bit by bit simultaneously with join->map2table list. Obviously join->map2table never contains an entry for the OUTER_REF_TABLE_BIT pseudo-table, so the server crashed there. The only_eq_ref_tables function has been modified to traverse regular table bits only like the update_depend_map function (resetting of the OUTER_REF_TABLE_BIT there is enough, but resetting of the whole set of PSEUDO_TABLE_BITS is used there for sure). mysql-test/r/order_by.result: Added test case for bug #39844. mysql-test/t/order_by.test: Added test case for bug #39844. sql/sql_select.cc: Bug #39844: Query Crash Mysql Server 5.0.67 The only_eq_ref_tables function has been modified to traverse regular table bits only like the update_depend_map function (resetting of the OUTER_REF_TABLE_BIT there is enough, but resetting of the whole set of PSEUDO_TABLE_BITS is used there for sure).
-
Georgi Kodinov authored
Added the missing DROP TABLE mysql-test/r/windows.result: Bug #39958: added the missing DROP TABLE mysql-test/t/windows.test: Bug #39958: added the missing DROP TABLE
-
Davi Arnaut authored
-
- 15 Oct, 2008 2 commits
-
-
Davi Arnaut authored
The problem is that the function used by the server to increase the thread's priority (pthread_setschedparam) has the unintended side-effect of changing the calling thread scheduling policy, possibly overwriting a scheduling policy set by a sysadmin. The solution is to rely on the pthread_setschedprio function, if available, as it only changes the scheduling priority and does not change the scheduling policy. This function is usually available on Solaris and Linux, but it use won't work by default on Linux as the the default scheduling policy only accepts a static priority 0 -- this is acceptable for now as priority changing on Linux is broken anyway. configure.in: Check for the existence of the pthread_setschedprio function. include/my_pthread.h: Use the pthread_setschedprio function to set the thread priority if the function is available.
-
Davi Arnaut authored
The problem is that MySQL's 'fast' mutex implementation uses the random() routine to determine the spin delay. Unfortunately, the routine interface is not thead-safe and some implementations (eg: glibc) might use a internal lock to protect the RNG state, causing excessive locking contention if lots of threads are spinning on a MySQL's 'fast' mutex. The code was also misusing the value of the RAND_MAX macro, this macro represents the largest value that can be returned from the rand() function, not random(). The solution is to use the quite simple Park-Miller random number generator. The initial seed is set to 1 because the previously used generator wasn't being seeded -- the initial seed is 1 if srandom() is not called. Futhermore, the 'fast' mutex implementation has several shortcomings and provides no measurable performance benefit. Therefore, its use is not recommended unless it provides directly measurable results. include/my_pthread.h: Add field to keep the RNG state. mysys/thr_mutex.c: Use a palliative per-mutex rng state to determine the spin delay. The RNG is not thread-safe but jumping a few sequences in the RNG is harmless.
-