MySQL Bugs: #19536: NDB replication fails when no explicit--binlog-format given

Bug #19536	NDB replication fails when no explicit--binlog-format given
Submitted:	4 May 2006 12:20	Modified:	4 May 2006 18:14
Reporter:	Kristian Nielsen	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Replication	Severity:	S2 (Serious)
Version:	5.1.10 (latest bitkeeper)	OS:	Any (All)
Assigned to:	Antony Curtis	CPU Architecture:	Any

Description:
After the push of WL#3201, NDB replication fails if no explicit --binlog-format=row is given.

How to repeat:
$ mysql-test-run.pl rpl_ndb_UUID
rpl_ndb_UUID                   [ fail ]

Errors are (from /dev/shm/v4/log/mysqltest-time) :
mysqltest: In included file "./extra/rpl_tests/rpl_row_UUID.test": At line 75: command "diff $MYSQLTEST_VARDIR/tmp/rpl_row_UUID_master.sql $MYSQLTEST_VARDIR/tmp/rpl_row_UUID_slave.sql;" failed

Note that these both work as expected:

$ mysql-test-run.pl --binlog-format=row rpl_ndb_UUID
$ mysql-test-run.pl --binlog-format=statement rpl_ndb_UUID

Suggested fix:
The problem seems to be that the WL#3201 patch changes the initialization order, so that the processing of the binlog-format in NDB and in the main server are no longer working together.

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

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Pushed to 5.1.10-beta repository

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

ChangeSet@1.2275, 2006-10-02 12:54:26-04:00, cmiller@zippy.cornsilk.net +3 -0
  Bug#19536: Assert on undefined @uservar in prepared statement execute
  
  The executing code had a safety assertion so that it refused to free Items
  that it didn't create.  However, there is a case, undefined user variables,
  which would put Items into the list to be freed.
  
  Instead, do something that is more risky in expectation that the code will 
  be refactored soon, as Kostja wants to do:  Remove the assertions from 
  prepare() and execute().  Put one assertion at a higher level, before 
  stmt->set_params_from_vars(), which may then create new to-be-freed Items .

The last patch is for bug#19356, not this one.