MySQL Bugs: #46640: output from mysqlbinlog command in 5.1 breaks replication

Bug #46640	output from mysqlbinlog command in 5.1 breaks replication
Submitted:	10 Aug 2009 22:54	Modified:	19 Dec 2009 11:07
Reporter:	Ryan Huddleston	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Row Based Replication ( RBR )	Severity:	S2 (Serious)
Version:	5.1.36	OS:	Any
Assigned to:	Daogang Qu	CPU Architecture:	Any
Tags:	regression

Description:
We extensively use mysqlbinlog in 5.0 to move database between different servers, Clone a database then catch the data up (roll-forward). Restore from backups and roll-forward etc.

The problem is that in 5.1 the mysqbinlog command outputs the "format description BINLOG statement" at the top of the mysqlbinlog output e.g.:

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#090810 15:14:07 server id 13  end_log_pos 106  Start: binlog v 4, server v 5.1.36-log created 090810 15:14:07
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
BINLOG '
n42ASg8NAAAAZgAAAGoAAAABAAQANS4xLjM2LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;

This is very dangerous as when I pipe this into another server it overrides the server_id setting from that server and logs it as the wrong server_id
 
Another side effect of this is we have one server that runs all the mysqlbinlog commands and the newerer mysqlbinlog binary breaks when piping 5.0 binlogs to 5.0 servers as they don't understand the "format description BINLOG statement"

How to repeat:
# DB server 1
create database foo;
use foo;
create table foo (foo int) engine=innodb;
flush logs;
insert into foo values (1), (2);
show master status; # grab File

# DB server 2 (in dual master configuration with DB server 3)
create database foo;
use foo;
create table foo (foo int) engine=innodb;
mysqlbinlog --database=foo <binlog file above> | mysql -h <dbserver #2> foo
mysql -h <dbserver #2> foo
mysql> select count(*) from foo; #notice this number is growing rapidly
# drop the foo table before the disk on your server fills up!

Suggested fix:
I'm trying to understand the relationship between the "format description BINLOG statement" and the server_id. It seems to me that the server_id stored in the "format description BINLOG statement" should never override the server_id of the server executing the statements. 

* If the connection reading the SQL statements is not the SQL replication thread then it should ignore the server_id contained in the "format description BINLOG statement". 
* If the above can't be fixed quickly having an option to override the server_id encoded in the "format description BINLOG statement" with a new server_id via a command line option to mysqlbinlog

Additionally:
* Don't output the "format description BINLOG statement" when reading mysql 5.0 binlogs

Many thanks for writing a bug report.

Verified as described.

Hi Ryan!

In order to avoid emitting the Format description log event, use the option --base64-output=never. However, this only works for binary logs not containing  RBR events, since it will give an error if there are RBR events in the binary log.

Piping output from mysqlbinlog in this manner should not change the server_id, so we will investigate what is the problem.

Mats I investigated --base64-output=never but that requires I do binlog_format=STATEMENT but I can't do this as switching to STATEMENT based replication breaks applications where 'READ-COMMITTED' is used as they get this error:

Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'

It seems this problem was introduced with the patch for Bug#32407.

This patch makes mysqlbinlog output the format description event, which is
needed to correctly execute BINLOG statements.

However the patch also introduces an unrelated change which makes BINLOG
statements share more of the code path used to execute binlog events in the
slave sql thread. This includes using the server id of the event rather than
that of the running server, as well as other things that seem redundant or
wrong for executing the BINLOG statement.

I added some discussion of the issue here:

    http://askmonty.org/worklog/Server-RawIdeaBin/index.pl?tid=50

Maybe the offending part of the patch for Bug#32407 should be reverted.

By the way, as far as I can see in the code, the server id problem is not
related to the format description event. Rather, _every_ event in BINLOG
statements is applied with the originating server id in MySQL >=5.1.24 (after
patch for Bug#32407).

Kristian, I think you are right, we should not set server_id (or date) when executing BINLOG statements. I think the fix is to just move the lines

  thd->server_id = ev->server_id; // use the original server id for logging
  thd->set_time();                            // time the query

away from apply_event_and_update_pos and into exec_relay_log_event. This reverts part of my patch for BUG#32407 (where the lines were moved from exec_relay_log_event to apply_event_and_update_pos).

Just a remark on your worklog: I don't understand the comment "2. When one applies 'format description binlog statement' at the slave, it will change the slave's server_id when applied." found under high-level description. I don't think this is true. The slave sql thread only remembers the server_id so that the event can be logged with the server_id of the originating server (to make circular replication work). I don't think the slave server's server_id is changed.

Did you mean "2. When one executes a BINLOG statement containing a format_description_log_event, it will change the client's server_id and subsequent statments executed in the same client will be logged with the server_id of the format_description_log_event"? I think that is part of this bug and it will be solved by moving the two lines as above.

Hi Ryan,

If mysqlbinlog is from 5.0, it will not output Format_description_events. If mysqlbinlog is from 5.1, it will output Format_description_events unless you specify --base64-output=never. The flag --base64-output=never only works on binlogs that do not contain any row events. So you can use --base64-output=never when you read binlogs from 5.0 servers, and omit --base64-output=never when you read binlogs from 5.1 servers.

I agree that it would be better if mysqlbinlog from 5.1 did not output Format_description_events when reading a binlog generated by a 5.0 server. But you can use the fix above until that is fixed.

Sven,

Thanks for your comments. Yes, agree with your interpretation of the worklog,
thanks for the clarification.

Agree that moving the two lines you suggested will fix the server id
issue. But it seems to me that this would still leave code in
apply_event_and_update_pos() that is redundant in the case of BINLOG statement
execution:

    thd->lex->current_select= 0;
    ev->thd = thd

This is redundant, as it it already done earlier in the execution of a
statement.

    if (!ev->when) ev->when= my_time(0)

I think this is redundant, not 100% sure though.

    ev->update_pos(rli)

This seems confusing to have in the execution of a BINLOG statement. At best
it is probably harmless, as the rli is the "fake" rli constructed for
executing BINLOG statements only. But there seems no point, and it causes
complications for every change in update_pos()-related code, as it must be
carefully checked that these changes have no effect in the case of BINLOG
statement. Why do it at all?

When I checked the update_pos() related code, I found only once action that
seemed to have effect for BINLOG: the setting of
rli->relay_log.description_event_for_exec for the format description
event. But this would in any case be cleaner to do inside
mysql_client_binlog_statement(), keeping the description_event_for_exec as a
local variable, and simplifying the memory management for this one.

That is why I suggest to replace the call of apply_event_and_update_pos() in
mysql_client_binlog_statement() with a direct call to ev->apply_event(), and
explicitly handle description_event_for_exec in the finction. Or am I missing
something?

Kristian, the ev->update_pos() is also needed for BINLOG statements that contain a row event, becuase it does some cleanup (including flushing row events to binlog and calling ha_autocommit_or_rollback()). But I think this too is a bit weird to do in ev->update_pos(), so that should probably also be moved to ev->apply_event().

It seems straightforward to move code freely between update_pos and apply_event, because they are only called from apply_event_and_update_pos(), and a call to apply_event() is always followed by a call to update_pos() (unless apply_event failed) and update_pos() is always preceded by a call to apply_event().

So I agree, we should at least invetigate the possibility to refactor so that we can call apply_event() directly from mysql_client_binlog_statement.

Committed a possible fix along the lines discussed above:

    https://lists.launchpad.net/maria-developers/msg00926.html

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/84587

3117 Dao-Gang.Qu@sun.com	2009-09-25
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/84781

3117 Dao-Gang.Qu@sun.com	2009-09-28
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/84934

3117 Dao-Gang.Qu@sun.com	2009-09-29
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/84990

3117 Dao-Gang.Qu@sun.com	2009-09-29
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/85471

3146 Dao-Gang.Qu@sun.com	2009-10-02
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Move rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/86258

3146 Dao-Gang.Qu@sun.com	2009-10-09
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/86620

3162 Dao-Gang.Qu@sun.com	2009-10-13
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/86651

3649 Dao-Gang.Qu@sun.com	2009-10-13 [merge]
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/86746

3165 Dao-Gang.Qu@sun.com	2009-10-14
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

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/86747

3654 Dao-Gang.Qu@sun.com	2009-10-14 [merge]
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
     @ mysql-test/extra/binlog_tests/binlog.test
        Added test to verify if the server_id stored in the 'format 
        description BINLOG statement' will override the server_id
        of the server executing the statements.
     @ mysql-test/suite/binlog/r/binlog_row_binlog.result
        Test result for bug#46640
     @ mysql-test/suite/binlog/r/binlog_stm_binlog.result
        Test result for bug#46640
     @ sql/log_event.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
        
        Moved setting of rli->relay_log.description_event_for_exec from 
        Format_description_log_event::do_update_pos() to 
        Format_description_log_event::do_apply_event()
     @ sql/log_event_old.cc
        Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
        makes more sense, and is needed as update_pos() is no longer called when executing
        BINLOG statements.
     @ sql/slave.cc
        The skip flag is no longer needed, as the code path for BINLOG statement has been 
        cleaned up.
     @ sql/sql_binlog.cc
        Don't invoke the update_pos() code path for the BINLOG statement, as it contains code 
        that is redundant and/or harmful (especially setting thd->server_id).

Unfortunately  the bug contains two coding errors that turn up as warnings. Please fix ASAP

sql/log_event.cc: 7544
	suggest parentheses around assignment used as truth value

+    if (error= rows_event_stmt_cleanup(rli, thd))

sql/log_event_old.cc: 1845
	suggest parentheses around assignment used as truth value

+    if (error= trans_commit_stmt(thd))

Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version source revid:alik@sun.com-20091019135554-s1pvptt6i750lfhv) (merge vers: 6.0.14-alpha) (pib:13)

Pushed into 5.5.0-beta (revid:alik@sun.com-20091022060553-znkmxm0g0gm6ckvw) (version source revid:alik@sun.com-20091019131708-bc6pv55x6287a0wc) (merge vers: 5.5.0-beta) (pib:13)

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/87874

3191 Dao-Gang.Qu@sun.com	2009-10-23
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
      
      Added parentheses around assignment used as truth value for suppressing warnings.

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/87878

3684 Dao-Gang.Qu@sun.com	2009-10-23 [merge]
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication
      
      Added parentheses around assignment used as truth value for suppressing warnings.

The warnings were be suppressed.

Pushed into 5.1.41 (revid:joro@sun.com-20091104092152-qz96bzlf2o1japwc) (version source revid:kristofer.pettersson@sun.com-20091103162305-08l4gkeuif2ozsoj) (merge vers: 5.1.41) (pib:13)

Documented bugfix in the 5.1.41, 5.5.0, and 6.0.14 changelogs:

        A problem with the BINLOG statement in the output from
        mysqlbinlog could break replication; statements could be logged
        with the server ID stored within events by the BINLOG statement
        rather than the ID of the running server. With this fix, the
        server ID of the server executing the statements can no longer
        be overridden by the server ID stored in the binary log format
        description statement.

Closed.

Pushed into 6.0.14-alpha (revid:alik@sun.com-20091110093407-rw5g8dys2baqkt67) (version source revid:alik@sun.com-20091109080109-7dxapd5y5pxlu08w) (merge vers: 6.0.14-alpha) (pib:13)

Pushed into 5.5.0-beta (revid:alik@sun.com-20091109115615-nuohp02h8mdrz8m2) (version source revid:alik@sun.com-20091105092041-sp6eyod7sdlfuj3b) (merge vers: 5.5.0-beta) (pib:13)

Re-closed. See my previous comment.

Pushed into 5.1.41-ndb-7.1.0 (revid:jonas@mysql.com-20091218102229-64tk47xonu3dv6r6) (version source revid:jonas@mysql.com-20091218095730-26gwjidfsdw45dto) (merge vers: 5.1.41-ndb-7.1.0) (pib:15)

Pushed into 5.1.41-ndb-6.2.19 (revid:jonas@mysql.com-20091218100224-vtzr0fahhsuhjsmt) (version source revid:jonas@mysql.com-20091217101452-qwzyaig50w74xmye) (merge vers: 5.1.41-ndb-6.2.19) (pib:15)

Pushed into 5.1.41-ndb-6.3.31 (revid:jonas@mysql.com-20091218100616-75d9tek96o6ob6k0) (version source revid:jonas@mysql.com-20091217154335-290no45qdins5bwo) (merge vers: 5.1.41-ndb-6.3.31) (pib:15)

Pushed into 5.1.41-ndb-7.0.11 (revid:jonas@mysql.com-20091218101303-ga32mrnr15jsa606) (version source revid:jonas@mysql.com-20091218064304-ezreonykd9f4kelk) (merge vers: 5.1.41-ndb-7.0.11) (pib:15)

No additional changelog entries needed. Closed.