- 05 Jan, 2011 7 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Nirbhay Choubey authored
Updating the local repository.
-
Marc Alff authored
-
Nirbhay Choubey authored
Modifications in mysql-5.5 engines test suite.
-
Nirbhay Choubey authored
-
Nirbhay Choubey authored
Modifications in mysql-5.1 engines test suite.
-
- 04 Jan, 2011 3 commits
-
-
Jon Olav Hauglid authored
No conflicts.
-
Jon Olav Hauglid authored
This assert could be triggered if -1 was inserted into an auto increment column by a statement writing more than one row. Unless explicitly given, an interval of auto increment values is generated when a statement first needs an auto increment value. The triggered assert checks that the auto increment counter is equal to or higher than the lower bound of this interval. Generally, the auto increment counter starts at 1 and is incremented by 1 each time it is used. However, inserting an explicit value into the auto increment column, sets the auto increment counter to this value + 1 if this value is higher than the current value of the auto increment counter. This bug was triggered if the explicit value was -1. Since the value was converted to unsigned before any comparisons were made, it was found to be higher than the current vale of the auto increment counter and the counter was set to -1 + 1. This value was below the reserved interval and caused the assert to be triggered the next time the statement tried to write a row. With the patch for Bug#39828, this bug is no longer repeatable. Now, -1 + 1 is detected as an "overflow" which causes the auto increment counter to be set to ULONGLONG_MAX. This avoids hitting the assert for the next insert and causes a new interval of auto increment values to be generated. This resolves the issue. This patch therefore only contains a regression test and no code changes. Test case added to auto_increment.test.
-
Marc Alff authored
Fixed the test case to be independent of build options used. Removed the lowercase-table-names constraint, since performance schema tables are now in lowercase.
-
- 03 Jan, 2011 2 commits
-
-
Mikael Ronstrom authored
-
Tor Didriksen authored
-
- 31 Dec, 2010 2 commits
-
-
Guilhem Bichot authored
-
Guilhem Bichot authored
so will be run only weekly; this closes BUG#50595.
-
- 30 Dec, 2010 1 commit
-
-
Dmitry Shulga authored
-
- 29 Dec, 2010 8 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
unknown authored
mysqlbinlog only prints "use $database" statements to its output stream when the active default database changes between events. This will cause "No Database Selected" error when dropping and recreating that database. To fix the problem, we clear print_event_info->db when printing an event of CREATE/DROP/ALTER database statements, so that the Query_log_event after such statements will be printed with the use 'db' anyway except transaction keywords. mysql-test/r/mysqlbinlog.result: Test result for Bug#50914. mysql-test/t/mysqlbinlog.test: Added test to verify if the approach of the mysqlbinlog prints "use $database" statements to its output stream will cause "No Database Selected" error when dropping and recreating that database. sql/log_event.cc: Updated code to clear print_event_info->db when printing an event of CREATE/DROP/ALTER database statements, so that the Query_log_event after such statements will be printed with the use 'db' anyway except transaction keywords.
-
unknown authored
mysqlbinlog only prints "use $database" statements to its output stream when the active default database changes between events. This will cause "No Database Selected" error when dropping and recreating that database. To fix the problem, we clear print_event_info->db when printing an event of CREATE/DROP/ALTER database statements, so that the Query_log_event after such statements will be printed with the use 'db' anyway except transaction keywords. mysql-test/r/mysqlbinlog.result: Test result for Bug#50914. mysql-test/t/mysqlbinlog.test: Added test to verify if the approach of the mysqlbinlog prints "use $database" statements to its output stream will cause "No Database Selected" error when dropping and recreating that database. sql/log_event.cc: Updated code to clear print_event_info->db when printing an event of CREATE/DROP/ALTER database statements, so that the Query_log_event after such statements will be printed with the use 'db' anyway except transaction keywords.
-
Kent Boortz authored
-
- 28 Dec, 2010 2 commits
-
-
Kent Boortz authored
-
Kent Boortz authored
- Removed files specific to compiling on OS/2 - Removed files specific to SCO Unix packaging - Removed "libmysqld/copyright", text is included in documentation - Removed LaTeX headers for NDB Doxygen documentation - Removed obsolete NDB files - Removed "mkisofs" binaries - Removed the "cvs2cl.pl" script - Changed a few GPL texts to use "program" instead of "library"
-
- 24 Dec, 2010 2 commits
-
-
Sergey Glukhov authored
-
Sergey Glukhov authored
ASSERT happens due to improper calculation of the max_length in Item_func_div object, if dividend has max_length == 0 then Item_func_div::max_length is set to 0 under some circumstances. The fix: If decimals == NOT_FIXED_DEC then set Item_func_div::max_length to max possible DOUBLE length value. mysql-test/r/func_math.result: test case mysql-test/t/func_math.test: test case sql/item_func.cc: The fix: If decimals == NOT_FIXED_DEC then set Item_func_div::max_length to max possible DOUBLE length value.
-
- 21 Dec, 2010 13 commits
-
-
Anitha Gopi authored
BUG #59055: RQG was broken after the checkin that removed rpl and rpl_ndb suites. RQG uses MTR V1 and that still has these in the default suite. Removing these from V1. Also removing references to ndb tests in some more disabled.def files
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sven Sandberg authored
Problem: master executed a statement that would fail on slave (namely, DROP USER 'create_rout_db'@'localhost'). Then the test did: --let $rpl_only_running_threads= 1 --source include/rpl_reset.inc rpl_reset.inc calls rpl_sync.inc, which first checks which of the threads are running and then syncs those threads that are running. If the SQL thread fails after the check, the sync will fail. So there was a race in the test and it failed on some slow hosts. Fix: Don't replicate the failing statement.
-
Tor Didriksen authored
cmake/os/SunOS.cmake: Remove TARGET_OS_SOLARIS config.h.cmake: Remove TARGET_OS_SOLARIS Add PTHREAD_ONCE_INITIALIZER configure.cmake: Add function for testing whether we need { PTHREAD_ONCE_INIT } rather than PTHREAD_ONCE_INIT include/my_pthread.h: Use PTHREAD_ONCE_INITIALIZER if set by cmake. include/mysql/psi/mysql_file.h: Include my_global.h first, to get correct platform definitions. mysys/ptr_cmp.c: Hide the unused static functions in #ifdef's on solaris. Use __sun (defined by both gcc and SunPro cc) rather than TARGET_OS_SOLARIS sql/my_decimal.cc: Include my_global.h first, to get correct platform definitions. sql/mysqld.cc: Fix signed/unsigned comparison warning. sql/sql_audit.h: Include my_global.h first, to get correct platform definitions. sql/sql_plugin.h: Include my_global.h first, to get correct platform definitions. sql/sql_show.cc: Fix: warning: cast from pointer to integer of different size sql/sys_vars.h: Use reinterpret_cast rather than c-style cast. storage/perfschema/pfs_instr.cc: Include my_global.h first, to get correct platform definitions.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sven Sandberg authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
Item_sum_max/Item_sum_min incorrectly set null_value flag and attempt to get result in parent functions leads to crash. This happens due to double evaluation of the function argumet. First evaluation happens in the comparator and second one happens in Item_cache::cache_value(). The fix is to introduce new Item_cache object which holds result of the argument and use this cached value as an argument of the comparator. mysql-test/r/func_group.result: test case mysql-test/t/func_group.test: test case sql/item.cc: added assertion that ether we have some result or result is NULL. sql/item_sum.cc: introduce new Item_cache object which holds result of the argument and use this cached value as an argument of the comparator. sql/item_sum.h: introduce new Item_cache object which holds result of the argument and use this cached value as an argument of the comparator.
-
unknown authored
Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event. mysql-test/extra/rpl_tests/rpl_auto_increment.test: Added test to verify if the assertion of "next_insert_id == 0" will fail in ha_external_lock() function. mysql-test/suite/rpl/r/rpl_auto_increment.result: Test result for bug#56662. sql/log_event.cc: Added code to not allow generation of auto_increment value when processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode. sql/rpl_record.cc: Added code to get rid of the 'MODE_STRICT_TRANS_TABLES' and MODE_STRICT_ALL_TABLES check to the table when appling the rows event and treat it as no strict.
-
Sven Sandberg authored
-