List:Commits« Previous MessageNext Message »
From:Sven Sandberg Date:December 21 2010 12:17pm
Subject:bzr push into mysql-5.5-bugteam branch (sven.sandberg:3219 to 3220) Bug#59084
View as plain text  
 3220 Sven Sandberg	2010-12-21 [merge]
      Merged fix for BUG#59084 from 5.1-bugteam to 5.5-bugfixing

    modified:
      mysql-test/suite/rpl/r/rpl_do_grant.result
      mysql-test/suite/rpl/t/rpl_do_grant.test
 3219 Dao-Gang.Qu@stripped	2010-12-21 [merge]
      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:15:12 +0000
+++ b/mysql-test/suite/rpl/r/rpl_do_grant.result	2010-12-21 12:14:22 +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:15:12 +0000
+++ b/mysql-test/suite/rpl/t/rpl_do_grant.test	2010-12-21 12:14:22 +0000
@@ -208,10 +208,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.5-bugteam branch (sven.sandberg:3219 to 3220) Bug#59084Sven Sandberg21 Dec