- 18 Dec, 2009 1 commit
-
-
Magne Mahre authored
Bug#35589 SET PASSWORD caused a crash Bug#35591 FLUSH PRIVILEGES caused a crash A race condition on the privilege hash tables (proc_priv_hash and func_priv_hash) caused one thread to try to delete elements that had already been deleted by another thread. The bug was caused by reading and saving the pointers to the hash tables outside mutex protection. This led to an inconsistency where a thread copied a pointer to a hash, another thread did the same, the first thread then deleted the hash, and the second then crashed when it in turn tried to delete the deleted hash. The fix is to ensure that operations on the shared hash structures happens under mutex protection (moving the locking up a little)
-
- 17 Dec, 2009 11 commits
-
-
Jim Winstead authored
-
Jim Winstead authored
-
Alfranio Correia authored
-
Andrei Elkin authored
-
Andrei Elkin authored
The test allowed random coincidence of connection ids for two concurrent sessions performing CREATE/DROP temp tables. Fixed with correcting the test. The sessions connection ids are not changed from their defaults anymore.
-
Satya B authored
-
Satya B authored
-
Satya B authored
When compressed myisam files are opened, they are always memory mapped sometimes causing memory swapping problems. When we mmap the myisam compressed tables of size greater than the memory available, the kswapd0 process utilization is very high consuming 30-40% of the cpu. This happens only with linux kernels older than 2.6.9 With newer linux kernels, we don't have this problem of high cpu consumption and this option may not be required. The option 'myisam_mmap_size' is added to limit the amount of memory used for memory mapping of myisam files. This option is not dynamic. The default value on 32 bit system is 4294967295 bytes and on 64 bit system it is 18446744073709547520 bytes. Note: Testcase only tests the option variable. The actual bug has be to tested manually. include/my_global.h: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() define SIZE_T_MAX include/myisam.h: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() declare 'myisam_mmap_size' and 'myisam_mmap_used' variables and the mutex THR_LOCK_myisam_mmap myisam/mi_packrec.c: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() add 'myisam_mmap_size' option which limits the memory available to mmap of myisam files myisam/mi_static.c: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() declare 'myisam_mmap_size' and 'myisam_mmap_used' variables and the mutex THR_LOCK_myisam_mmap myisam/myisamdef.h: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() move MEMMAP_EXTRA_MARGIN to myisam.h so that it can be used in mysqld.cc mysql-test/r/variables.result: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() Testcase for BUG#37408 to test the myisam_mmap_size option mysql-test/t/variables.test: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() Testcase for BUG#37408 to test the myisam_mmap_size option mysys/my_thr_init.c: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() intialize the lock THR_LOCK_myisam_mmap sql/mysqld.cc: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() add the 'myisam_mmap_size' option sql/set_var.cc: Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap() add the 'myisam_mmap_size' to the SHOW VARIABLES list
-
Martin Hansson authored
returns incorrect results with where An outer join of a const table (outer) and a normal table (inner) with GROUP BY on a field from the outer table would optimize away GROUP BY, and thus trigger the optimization to do away with a temporary table if grouping was performed on columns from the const table, hence executing the query with filesort without temporary table. But this should not be done if there is a non-indexed access to the inner table, since filesort does not handle joins. It expects either ref access, range ditto or table scan. The join condition will thus not be applied. Fixed by always forcing execution with temporary table in the case of ROLLUP with a query involving an outer join. This is a slightly broader class of queries than need fixing, but it is hard to ascertain the position of a ROLLUP field wrt outer join with current query representation. mysql-test/r/join_outer.result: Bug#47650: Test result mysql-test/t/join_outer.test: Bug#47650: Test case sql/sql_select.cc: Bug#47650: Fix
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
Problem: inserting a record we don't set unused null bits in the record buffer if no default field values used. That may lead to wrong live checksum calculation. Fix: set unused null bits in the record buffer in such cases. mysql-test/r/myisam.result: Fix for bug#49465: valgrind warnings and incorrect live checksum... - test result. mysql-test/t/myisam.test: Fix for bug#49465: valgrind warnings and incorrect live checksum... - test case. sql/sql_insert.cc: Fix for bug#49465: valgrind warnings and incorrect live checksum... - set unused null bits to 1 in the record buffer in case we don't call restore_record() before a fill_record() call (when no default values used).
-
- 16 Dec, 2009 6 commits
-
-
Jim Winstead authored
-
Magne Mahre authored
The bug is caused by a race condition between the INSERT DELAYED thread and the client thread's FLUSH TABLE. The FLUSH TABLE does not guarantee (as is (wrongly) suggested in the test case) that the INSERT DELAYED is ever executed. The execution of the test case will thus not be deterministic. The fix has been to do a deterministic verification that both threads are complete by checking the content of the table.
-
Alfranio Correia authored
Calling push_warning/push_warning_printf with a level of WARN_LEVEL_ERROR *is* a bug. We should either use my_error(), or WARN_LEVEL_WARN.
-
Georgi Kodinov authored
-
unknown authored
This test case tests a circular replication of four hosts. A--->B--->C--->D--->A The replicate is slow and needs more time to replicate all data in the circle. The time it spends to replicate, sometimes, is longer than the time that wait_condition.inc spends to wait that all data has been replicated. This cause sporadical failure of this test case. This patch uses sync_slave_with_master to ensure that all data can be replicated successfully in the circle.
-
unknown authored
Only relative log events are showed.
-
- 15 Dec, 2009 8 commits
-
-
Georgi Kodinov authored
int join_read_key(JOIN_TAB*) The eq_ref access method TABLE_REF (accessed through JOIN_TAB) to save state and to track if this is the first row it finds or not. This state was not reset on subquery re-execution causing an assert. Fixed by resetting the state before the subquery re-execution.
-
Georgi Kodinov authored
-
Mattias Jonsson authored
-
Georgi Kodinov authored
int join_read_key(JOIN_TAB*) The eq_ref access method TABLE_REF (accessed through JOIN_TAB) to save state and to track if this is the first row it finds or not. This state was not reset on subquery re-execution causing an assert. Fixed by resetting the state before the subquery re-execution.
-
Alexander Barkov authored
Problem: add_collation did not check that cs->number is smaller than the number of elements in the array all_charsets[], so server could crash when loading an Index.xml file with a collation ID greater the number of elements (for example when downgrading from 5.5). Fix: adding a condition to check that cs->number is not out of valid range.
-
Jon Olav Hauglid authored
check_key_in_view() had one code branch which returned with "return TRUE" rather than "DBUG_RETURN(TRUE)". Only affected debug builds. No test case added.
-
He Zhenxing authored
Problem is that purge_logs implementation in ndb (ndbcluster_binlog_index_purge_file) calls mysql_parse (with (thd->options & OPTION_BIN_LOG) === 0)) but MYSQL_BIN_LOG first takes LOCK_log and then checks thd->options Solution in this patch, changes so that rotate_and_purge does not hold LOCK_log when calling purge_logs_before_date. I think this is safe as other "purge"-function(s) is called wo/ holding LOCK_log, e.g purge_master_logs
-
unknown authored
'LOAD DATA CONCURRENT [LOCAL] INFILE ...' statment only is binlogged as 'LOAD DATA [LOCAL] INFILE ...' in SBR and MBR. As a result, if replication is on, queries on slaves will be blocked by the replication SQL thread. This patch write code to write 'CONCURRENT' into the log event if 'CONCURRENT' option is in the original statement in SBR and MBR.
-
- 14 Dec, 2009 9 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
All tests in the parts suite that use partitioning on a timezone-dependent expression were commented out, since it is not valid anymore.
-
Andrei Elkin authored
-
Andrei Elkin authored
-
Mattias Jonsson authored
Includes both patch from bug#48737 (without test, which should go to next-mr) and test for bug#49028.
-
Andrei Elkin authored
-
Satya B authored
When applying innodb snapshot 1.0.6 the storage engine name for innodb plugin under windows was changed from INNODB_PLUGIN to INNOBASE. This is a wrong and changing back the name to INNODB_PLUGIN. storage/innodb_plugin/CMakeLists.txt: Fix for BUG#49502 - CMake error compiling 5.1 on Windows Change the storage engine name to INNODB_PLUGIN in CMakeLists.txt
-
Alexey Kopytov authored
-
unknown authored
-
- 13 Dec, 2009 3 commits
-
-
unknown authored
5.0 buffer overflow for ER_UPDATE_INFO, or truncated info message in 5.1 5.0.86 has a buffer overflow/crash, and 5.1.40 has a truncated message. errmsg.txt contains this: ER_UPDATE_INFO rum "Linii identificate (matched): %ld Schimbate: %ld Atentionari (warnings): %ld" When that is sprintf'd into a buffer of STRING_BUFFER_USUAL_SIZE size, a buffer overflow can happen. The solution to this is to use MYSQL_ERRMSG_SIZE for the buffer size, instead of STRING_BUFFER_USUAL_SIZE. This will allow longer strings. To avoid potential crashes, we will also use my_snprintf instead of sprintf. sql/sql_update.cc: sing MYSQL_ERRMSG_SIZE instead of STRING_BUFFER_USUAL_SIZE. Using my_snprintf instead of sprintf.
-
Alexey Kopytov authored
-
Alexey Kopytov authored
timestamp primary key Since TIMESTAMP values are adjusted by the current time zone settings in both numeric and string contexts, using any expressions involving TIMESTAMP values as a (sub)partitioning function leads to undeterministic behavior of partitioned tables. The effect may vary depending on a storage engine, it can be either incorrect data being retrieved or stored, or an assertion failure. The root cause of this is the fact that the calculated partition ID may differ from a previously calculated ID for the same data due to timezone adjustments of the partitioning expression value. Fixed by disabling any expressions involving TIMESTAMP values to be used in partitioning functions with the follwing two exceptions: 1. Creating or altering into a partitioned table that violates the above rule is not allowed, but opening existing such tables results in a warning rather than an error so that such tables could be fixed. 2. UNIX_TIMESTAMP() is the only way to get a timezone-independent value from a TIMESTAMP column, because it returns the internal representation (a time_t value) of a TIMESTAMP argument verbatim. So UNIX_TIMESTAMP(timestamp_column) is allowed and should be used to fix existing tables if one wants to use TIMESTAMP columns with partitioning. mysql-test/r/partition_bug18198.result: Corrected the error. mysql-test/r/partition_error.result: Corrected error texts. Added test cases for bug #42849. mysql-test/t/partition_bug18198.test: Corrected error code. mysql-test/t/partition_error.test: Corrected error codes. Added test cases for bug #42849. sql/item.h: Added is_timezone_dependent_processor() to Item. sql/item_func.h: Added has_timestamp_args() and the implementation of is_timezone_dependent_processor() for Item_func. sql/item_timefunc.h: Added is_timezone_dependent_processor() to Item_func_unix_timestamp. sql/share/errmsg.txt: Renamed ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR to ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR to better reflect the meaning. Adjusted the error message. sql/sql_partition.cc: Modified fix_fields_part_func() to walk through partitioning expression tree with is_timezone_dependent_processor() and issue a warning/error if it depends on the timezone settings. Changed fix_fields_part_func() to a static function since it is not used anywhere except sql_partition.cc sql/sql_partition.h: Removed the unneeded declaration of fix_fields_part_func() since it is now a static function. sql/sql_yacc.yy: ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR -> ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR.
-
- 12 Dec, 2009 1 commit
-
-
Staale Smedseng authored
As documented in the bug report, the double checked locking pattern has inherent issues, and cannot guarantee correct initialization. This patch replaces the logic in init_available_charsets() with the use of pthread_once(3). A wrapper function, my_pthread_once(), is introduced and is used in lieu of direct calls to init_available_charsets(). Related defines MY_PTHREAD_ONCE_* are also introduced. For the Windows platform, the implementation in lp:sysbench is ported. For single-thread use, a simple define calls the function and sets the pthread_once control variable. Charset initialization is modified to use my_pthread_once(). include/my_no_pthread.h: Dummy my_pthread_once() for single thread use. include/my_pthread.h: Declaration for new function my_pthread_once(). mysys/charset.c: Logic in init_available_charsets() is simplified. Using my_pthread_once() for all calls to this func. mysys/my_winthread.c: Windows implementation of my_pthread_once().
-
- 11 Dec, 2009 1 commit
-
-
Kent Boortz authored
compatibility, not to change the -D_WIN32_WINNT=0x0501 in 5.1, XP compatibility.
-