3531 Sven Sandberg 2010-12-21
BUG#59084: rpl_do_grant started to fail on FreeBSD (presumably after BUG#49978)
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.
modified:
mysql-test/suite/rpl/r/rpl_do_grant.result
mysql-test/suite/rpl/t/rpl_do_grant.test
3530 Dao-Gang.Qu@stripped 2010-12-21
Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc
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.
modified:
mysql-test/extra/rpl_tests/rpl_auto_increment.test
mysql-test/suite/rpl/r/rpl_auto_increment.result
sql/log_event.cc
sql/log_event.h
sql/rpl_record.cc
sql/rpl_record.h
=== modified file 'mysql-test/suite/rpl/r/rpl_do_grant.result'
--- a/mysql-test/suite/rpl/r/rpl_do_grant.result 2010-12-19 17:07:28 +0000
+++ b/mysql-test/suite/rpl/r/rpl_do_grant.result 2010-12-21 12:09:38 +0000
@@ -162,7 +162,9 @@ USE bug42217_db;
DROP FUNCTION upgrade_del_func;
DROP FUNCTION upgrade_alter_func;
DROP DATABASE bug42217_db;
+SET SQL_LOG_BIN= 0;
DROP USER 'create_rout_db'@'localhost';
+SET SQL_LOG_BIN= 1;
include/rpl_reset.inc
USE test;
######## BUG#49119 #######
=== modified file 'mysql-test/suite/rpl/t/rpl_do_grant.test'
--- a/mysql-test/suite/rpl/t/rpl_do_grant.test 2010-12-19 17:07:28 +0000
+++ b/mysql-test/suite/rpl/t/rpl_do_grant.test 2010-12-21 12:09:38 +0000
@@ -216,10 +216,10 @@ DROP DATABASE bug42217_db;
-- connection master
# user was already dropped in the slave before
-# so no need to wait for the slave to replicate
-# this statement (if it did and we later synced
-# the slave it would end up in an error anyway)
+# so we should not replicate this statement.
+SET SQL_LOG_BIN= 0;
DROP USER 'create_rout_db'@'localhost';
+SET SQL_LOG_BIN= 1;
# finish entire clean up (remove binlogs)
# so that we leave a pristine environment for the
No bundle (reason: useless for push emails).
| Thread |
|---|
| • bzr push into mysql-5.1-bugteam branch (sven.sandberg:3530 to 3531)Bug#49978 Bug#59084 | Sven Sandberg | 21 Dec |
