- 07 Jan, 2011 4 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Jimmy Yang authored
MAX_FULL_NAME_LEN in InnoDB to address possible insufficient name buffer Bug #59312 Approved by Sunny Bains
-
- 06 Jan, 2011 1 commit
-
-
Saikumar V authored
-
- 05 Jan, 2011 2 commits
-
-
Georgi Kodinov authored
-
Nirbhay Choubey authored
-
- 04 Jan, 2011 1 commit
-
-
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.
-
- 31 Dec, 2010 1 commit
-
-
Guilhem Bichot authored
so will be run only weekly; this closes BUG#50595.
-
- 29 Dec, 2010 4 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin 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.
-
- 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 1 commit
-
-
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.
-
- 23 Dec, 2010 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 21 Dec, 2010 5 commits
-
-
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.
-
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.
-
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.
-
- 20 Dec, 2010 1 commit
-
-
Sven Sandberg authored
Problem: Warnings for truncated data were generated on hosts with long host names because @@hostname was inserted into a CHAR(40) column. Fix: Change CHAR(40) to TEXT.
-
- 19 Dec, 2010 1 commit
-
-
Sven Sandberg authored
Major replication test framework cleanup. This does the following: - Ensure that all tests clean up the replication state when they finish, by making check-testcase check the output of SHOW SLAVE STATUS. This implies: - Slave must not be running after test finished. This is good because it removes the risk for sporadic errors in subsequent tests when a test forgets to sync correctly. - Slave SQL and IO errors must be cleared when test ends. This is good because we will notice if a test gets an unexpected error in the slave threads near the end. - We no longer have to clean up before a test starts. - Ensure that all tests that wait for an error in one of the slave threads waits for a specific error. It is no longer possible to source wait_for_slave_[sql|io]_to_stop.inc when there is an error in one of the slave threads. This is good because: - If a test expects an error but there is a bug that causes another error to happen, or if it stops the slave thread without an error, then we will notice. - When developing tests, wait_for_*_to_[start|stop].inc will fail immediately if there is an error in the relevant slave thread. Before this patch, we had to wait for the timeout. - Remove duplicated and repeated code for setting up unusual replication topologies. Now, there is a single file that is capable of setting up arbitrary topologies (include/rpl_init.inc, but include/master-slave.inc is still available for the most common topology). Tests can now end with include/rpl_end.inc, which will clean up correctly no matter what topology is used. The topology can be changed with include/rpl_change_topology.inc. - Improved debug information when tests fail. This includes: - debug info is printed on all servers configured by include/rpl_init.inc - User can set $rpl_debug=1, which makes auxiliary replication files print relevant debug info. - Improved documentation for all auxiliary replication files. Now they describe purpose, usage, parameters, and side effects. - Many small code cleanups: - Made have_innodb.inc output a sensible error message. - Moved contents of rpl000017-slave.sh into rpl000017.test - Added mysqltest variables that expose the current state of disable_warnings/enable_warnings and friends. - Too many to list here: see per-file comments for details.
-
- 17 Dec, 2010 8 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Luis Soares authored
Post-push fixes: - fixed platform dependent result files - appeasing valgrind warnings: Fault injection was also uncovering a previously existing potential mem leaks. For BUG#46166 testing purposes, fixed by forcing handling the leak when injecting faults.
-
- 16 Dec, 2010 7 commits
-
-
Luis Soares authored
Merging to latest mysql-5.1-bugteam.
-
Georgi Kodinov authored
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
"load data infile .." allowed for access to unautohorized tables. Due to a faulty if-statement it was possible to circumvent the secure_file_priv restriction.
-
Martin Hansson authored
-
Martin Hansson authored
-
Martin Hansson authored
-