Bug #5949 error code 1223 in binlog when using innobackup
Submitted: 7 Oct 2004 8:16 Modified: 11 Oct 2004 9:04
Reporter: Guilhem Bichot Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:4.0.21 only OS:Any (all)
Assigned to: Guilhem Bichot CPU Architecture:Any

[7 Oct 2004 8:16] Guilhem Bichot 
Description:
hen using innobackup, error 1223 "can't update because you have a conflicting read lock" gets into the binlog, thus causing replication to fail. But innobackup succeeds.
In fact this happens whenever someone has started a transaction, done some updates, then does FLUSH TABLES WITH READ LOCK, then COMMIT (all in the same connection).
That's specific to 4.0.21, because in 4.0.21 we introduced that COMMIT should care about the issued FLUSH TABLES WITH READ LOCK.
So the bug is just an error code which is wrongly set (thd->net.last_errno) in this case.

How to repeat:
see description.

Suggested fix:
As agreed with Heikki, we will in 4.0.22 relax things: when the *same* connection does a FLUSH TABLES WITH READ LOCK then COMMIT, the COMMIT will not care about the FLUSH. So, no error will be written to the binlog.
[11 Oct 2004 9:04] Guilhem Bichot 
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:

ChangeSet@1.2022.12.1, 2004-10-11 11:01:38+02:00, guilhem@mysql.com