Hi Daogang,
Patch approved.
Please, see some suggestions in-line.
Cheers.
On 12/08/2010 03:37 AM, Dao-Gang.Qu@stripped wrote:
> #At file:///home/daogang/bzrwork/bug56662/mysql-5.1-bugteam/ based on
> revid:bjorn.munch@stripped
>
> 3524 Dao-Gang.Qu@stripped 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.
I would go for:
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.
s/when appling the rows event and treat it as no strict/
when applying rows event/
> === modified file 'sql/log_event.cc'
> --- a/sql/log_event.cc 2010-10-23 12:55:44 +0000
> +++ b/sql/log_event.cc 2010-12-08 03:37:08 +0000
> @@ -7569,6 +7569,14 @@ int Rows_log_event::do_apply_event(Relay
> // Do event specific preparations
> error= do_before_row_operations(rli);
>
> + /*
> + Bug#56662 Assertion failed: next_insert_id == 0, file handler.cc
> + Don't allow generation of auto_increment value when processing
> + rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode.
> + */
s/by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to sql_mode/
by setting 'MODE_NO_AUTO_VALUE_ON_ZERO'
> + ulong saved_sql_mode= thd->variables.sql_mode;
> + thd->variables.sql_mode= MODE_NO_AUTO_VALUE_ON_ZERO;
> +
> // row processing loop
>
> while (error == 0&& m_curr_row< m_rows_end)
