Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc
Submitted: 8 Sep 2010 18:20 Modified: 4 Jan 2011 5:16
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Row Based Replication ( RBR ) Severity:S1 (Critical)
Version:5.1.50-debug, 5.1.51-debug OS:Any
Assigned to: Daogang Qu CPU Architecture:Any
Triage: Triaged: D1 (Critical)

[8 Sep 2010 18:20] Shane Bester
Description:
Version: '5.1.50-enterprise-gpl-advanced-debug'  socket: ''  port: 3307  MySQL Enterprise Server - Advanced Edition Debug (GPL)
100908 20:18:24 [Note] Slave SQL thread initialized, starting replication in log 'xp64-bin.002502' at position 3727, relay log '.\xp64-relay-bin.005004' position: 3871
Assertion failed: next_insert_id == 0, file .\handler.cc, line 4611

mysqld-debug.exe!my_sigabrt_handler()[mysqld.cc:2083]
mysqld-debug.exe!raise()[winsig.c:590]
mysqld-debug.exe!abort()[abort.c:71]
mysqld-debug.exe!_wassert()[assert.c:212]
mysqld-debug.exe!handler::ha_external_lock()[handler.cc:4611]
mysqld-debug.exe!unlock_external()[lock.cc:786]
mysqld-debug.exe!mysql_unlock_tables()[lock.cc:391]
mysqld-debug.exe!close_thread_tables()[sql_base.cc:1346]
mysqld-debug.exe!Relay_log_info::cleanup_context()[rpl_rli.cc:1210]
mysqld-debug.exe!rows_event_stmt_cleanup()[log_event.cc:7765]
mysqld-debug.exe!Rows_log_event::do_apply_event()[log_event.cc:7684]
mysqld-debug.exe!Log_event::apply_event()[log_event.h:1067]
mysqld-debug.exe!apply_event_and_update_pos()[slave.cc:2154]
mysqld-debug.exe!exec_relay_log_event()[slave.cc:2293]
mysqld-debug.exe!handle_slave_sql()[slave.cc:3077]
mysqld-debug.exe!pthread_start()[my_winthread.c:85]
mysqld-debug.exe!_callthreadstart()[thread.c:293]
mysqld-debug.exe!_threadstart()[thread.c:277]
kernel32.dll!FlsSetValue()

How to repeat:
will provide testcase later.
[9 Sep 2010 7:00] Shane Bester
must be imported to master using "source bug56662.sql". ignore any errors.... watch slave crash

Attachment: bug56662.sql (application/octet-stream, text), 227.83 KiB.

[9 Sep 2010 7:02] Shane Bester
debug binary asserts.
release binary has error in sql thread: 100909  9:02:30 [ERROR] Slave SQL: Could not execute Write_rows event on table test.t2; Duplicate entry '658' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log xp64-bin.000006, end_log_pos 58067, Error_code: 1062
[10 Sep 2010 22:18] Sveta Smirnova
Thank you for the report.

Verified as described. next-mr fails with "100911  1:18:12 [Warning] Slave: Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT. Error_code: 1666"
[21 Sep 2010 7:02] Daogang Qu
Hi Shane Bester,
When running bug56662.sql on master, how to ignore the following kind of errors?:

1.
mysqltest: At line 343: query 'insert into t2(id,data) values (abs(-29457)%25,abs(16111)%25) on duplicate key update id=values(id),data=values(data)' failed: 1062: Duplicate entry '11' for key 'data'

Their are about thirty similar errors, ignore them by Adding 'IGNORE'
keyword for related INSERT STATEMENT?

2.
mysqltest: At line 355: query 'start transaction' failed: 1399: XAER_RMFAIL: The command cannot be executed when global transaction is in the  ACTIVE state

Is it OK to remove the statement?

The bug is masked by lots of unusable statements in bug56662.sql file.
Could you Please generate a simple test case for reproducing the bug?
[21 Sep 2010 7:10] Shane Bester
hi again! 
Ignore previous comment :)

must be done using "source bug56662.sql" mysql client command.

this is because some of the commands cause connection to be cut after committing
and auto-reconnect is needed!
[21 Sep 2010 10:39] Daogang Qu
Hi Shane Bester,

I test it according to above comment.
But I still just can get two kinds of errors as following:

1.
ERROR 1062 (23000): Duplicate entry '2' for key 'data'
ERROR 1062 (23000): Duplicate entry '14' for key 'data'
ERROR 1062 (23000): Duplicate entry '7' for key 'data'
Query OK, 0 rows affected (0.00 sec)

2.
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the  PREPARED state
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the  PREPARED state
Query OK, 2 rows affected (0.00 sec)

Did not get the reported bugs.
[28 Sep 2010 8:48] Daogang Qu
Hi Shane Bester,
The reported problem can not reproduced on
mysql-5.1.50-enterprise-gpl-advanced-debug
according to your test method too.
Is it sporadic?
[28 Oct 2010 2:24] Daogang Qu
The bug can not be reproduced base on the Version: '5.1.50-enterprise-gpl-advanced-debug'.
[29 Oct 2010 5:52] Shane Bester
still repeatable on 5.1.51...

Master is started like this:
-----------------------------
mysqld-debug --no-defaults --console --skip-gr --skip-na --log-bin --server-id=1 --port=3306 --tmpdir=. --socket=sock --binlog-format=row

Slave is started like this:
----------------------------
mysqld-debug --no-defaults --console --skip-gr --skip-na  --server-id=2 --port=3308 --tmpdir=. --socket=sock

On slave:
-------------
change master to master_host='127.0.0.1', master_port=3306, master_user='root', master_password='';
start slave;

On Master:
-------------
mysql -uroot test --no-beep
source bug56662.sql

*slave crashes*

Sorry, but errors are needed for the testcase. This is why "source" command
must be used.

Assertion failed: next_insert_id == 0, file .\handler.cc, line 4611
  mysqld-debug.exe!my_sigabrt_handler()[mysqld.cc:2086]
  mysqld-debug.exe!raise()[winsig.c:590]
  mysqld-debug.exe!abort()[abort.c:71]
  mysqld-debug.exe!_wassert()[assert.c:212]
  mysqld-debug.exe!handler::ha_external_lock()[handler.cc:4611]
  mysqld-debug.exe!unlock_external()[lock.cc:786]
  mysqld-debug.exe!mysql_unlock_tables()[lock.cc:391]
  mysqld-debug.exe!close_thread_tables()[sql_base.cc:1346]
  mysqld-debug.exe!Relay_log_info::cleanup_context()[rpl_rli.cc:1210]
  mysqld-debug.exe!rows_event_stmt_cleanup()[log_event.cc:7765]
  mysqld-debug.exe!Rows_log_event::do_apply_event()[log_event.cc:7684]
  mysqld-debug.exe!Log_event::apply_event()[log_event.h:1067]
  mysqld-debug.exe!apply_event_and_update_pos()[slave.cc:2154]
  mysqld-debug.exe!exec_relay_log_event()[slave.cc:2293]
  mysqld-debug.exe!handle_slave_sql()[slave.cc:3077]
  mysqld-debug.exe!pthread_start()[my_winthread.c:85]
  mysqld-debug.exe!_callthreadstart()[thread.c:293]
  mysqld-debug.exe!_threadstart()[thread.c:277]
  kernel32.dll!FlsSetValue()
[1 Nov 2010 8:28] Daogang Qu
According to above way, I failed to start up the second server with error.
Could you double check its options?

But I can successfully start up the master servers as following steps:

1. Using manual gdb
perl mysql-test-run.pl --manual-gdb --start rpl_view

2. Start deamon for master server
./mysqld-debug --defaults-group-suffix=.1 --defaults-file=../mysql-test/var/my.cnf --consol

3. Start deamon for slave server
./mysqld-debug --defaults-group-suffix=.2 --defaults-file=../mysql-test/var/my.cnf --consol

4. Connect to master sever
./mysql -u root  --host localhost --port 13000

5. Connect to slave server
./mysql -u root  --host localhost --port 13001

6. On slave:
-------------
change master to master_host='127.0.0.1', master_port=13000, master_user='root',
master_password='';
start slave;

7. On master:
---------------
source bug56662.sql

Could you please try the above steps for checking if it can reproduce the bug too? But I can't reproduce it on 5.1.50 version. I will try it on 5.1.50 version
later.
[1 Nov 2010 8:30] Daogang Qu
s/ try it on 5.1.50 / try it on 5.1.51
[1 Nov 2010 9:51] Shane Bester
Daogang, you need --binlog-format=row
[25 Nov 2010 10:25] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/125001

3518 Dao-Gang.Qu@sun.com	2010-11-25
      Bug #56662  	Assertion failed: next_insert_id == 0, file .\handler.cc
      
      In RBR, sometimes the new value of next_insert_id will be generated
      for current row when updating the auto_increment field of a table on
      slave side. Which causes the error. This is a incorrect behavior.
      
      After the patch, we never generate a new value for next_insert_id
      for current row when updating the auto_increment field of a table
      on slave side in RBR.
     @ mysql-test/suite/rpl/r/rpl_assert.result
        Test result for bug#56662
     @ mysql-test/suite/rpl/t/rpl_assert.test
        Added test to verify if the assertion of "next_insert_id == 0"
        will fail in ha_external_lock() function.
     @ sql/handler.cc
        Added code to not generate a new value for next_insert_id
        for current row on slave side in RBR.
[6 Dec 2010 5:43] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/126100

3524 Dao-Gang.Qu@sun.com	2010-12-06
      Bug #56662  	Assertion failed: next_insert_id == 0, file .\handler.cc
      
      In RBR, sometimes the new value of next_insert_id will be generated
      for current row when updating the auto_increment field of a table on
      slave side. Which causes the error. This is a incorrect behavior.
      
      After the patch, we never generate a new value for next_insert_id
      for current row when updating the auto_increment field of a table
      on slave side in RBR.
     @ 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.
[8 Dec 2010 3:42] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/126283

3524 Dao-Gang.Qu@sun.com	2010-12-08
      Bug #56662  	Assertion failed: next_insert_id == 0, file .\handler.cc
      
      In RBR, the zero will fill auto_increment field of a table if add
      'MODE_NO_AUTO_VALUE_ON_ZERO' to current sql_mode, then reset the
      sql_mode without 'MODE_NO_AUTO_VALUE_ON_ZERO' in a transation. Just
      the last setting of the sql_mode will be binlogged for the transaction.
      On slave, the transaction will be executed under the sql_mode without
      'MODE_NO_AUTO_VALUE_ON_ZERO'. So the rows event with the 'zero' as the
      the value of auto_increment field in the transaction will cause generation
      of auto_increment value when applying it. Which causes the error.
      
      In fact, we never need generate a new next_insert_id for rows event
      when applying it on slave. So don't allow generation of auto_increment
      value when applying rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO'
      to current sql_mode.
      
      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. Because 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.
[10 Dec 2010 8:42] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/126507

3524 Dao-Gang.Qu@sun.com	2010-12-10
      Bug #56662  	Assertion failed: next_insert_id == 0, file .\handler.cc
      
      Normally, you generate the next sequence number 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
      next sequence number. 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 next sequence number 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.
[13 Dec 2010 3:12] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/126587

3524 Dao-Gang.Qu@sun.com	2010-12-13
      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.
[17 Dec 2010 10:08] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/127157

3527 Dao-Gang.Qu@sun.com	2010-12-17
      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.
[17 Dec 2010 10:23] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/127164

3209 Dao-Gang.Qu@sun.com	2010-12-17 [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.
[20 Dec 2010 6:12] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/127268

3446 Dao-Gang.Qu@sun.com	2010-12-20 [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.
[21 Dec 2010 4:55] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/127347

3530 Dao-Gang.Qu@sun.com	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.
[21 Dec 2010 5:08] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/127348

3218 Dao-Gang.Qu@sun.com	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.
[21 Dec 2010 10:32] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/127375

3219 Dao-Gang.Qu@sun.com	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.
[21 Dec 2010 10:47] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/127379

3458 Dao-Gang.Qu@sun.com	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.
[22 Dec 2010 21:31] Bugs System
Pushed into mysql-trunk 5.6.1 (revid:alexander.nozdrin@oracle.com-20101222212842-y0t3ibtd32wd9qaw) (version source revid:alexander.nozdrin@oracle.com-20101222212842-y0t3ibtd32wd9qaw) (merge vers: 5.6.1) (pib:24)
[29 Dec 2010 12:51] Bugs System
Pushed into mysql-5.1 5.1.55 (revid:alexander.nozdrin@oracle.com-20101229113432-o0c3f1pqklek1txm) (version source revid:alexander.nozdrin@oracle.com-20101229113109-ft3q9tewyueopxgf) (merge vers: 5.1.55) (pib:24)
[29 Dec 2010 12:52] Bugs System
Pushed into mysql-5.5 5.5.9 (revid:alexander.nozdrin@oracle.com-20101229113652-km2v993aurv7h79j) (version source revid:alexander.nozdrin@oracle.com-20101229113132-uonlbcc2uopff8yb) (merge vers: 5.5.9) (pib:24)
[4 Jan 2011 5:16] Jon Stephens
Documented bugfix in the 5.1.55 aqnd 5.5.9 changelogs as follows:

        By default, a value is generated for an AUTO_INCREMENT column by
        inserting either NULL or 0 into it. Setting the
        NO_AUTO_VALUE_ON_ZERO server SQL mode suppresses this behavior
        for 0, so that it occurs only when NULL is inserted.

        This behavior is also followed on a replication slave (by the
        slave SQL thread) when applying events that have been logged on
        the master using the statement-based format. However, when
        applying events that had been logged using the row-based format,
        NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to an
        assertion.

        To fix this issue, values for AUTO_INCREMENT columns are no
        longer generated when applying events that have been logged
        using the row-based row format, as this value is already
        contained in the changes applied on the slave.

No changelog entry required for 5.6.1, as this issue has not appeared in any 5.6 release.

Closed.