Fix for BUG#5949 "error code 1223 in binlog when using innobackup":

when one connection had done FLUSH TABLES WITH READ LOCK, some updates, and then COMMIT,
it was accepted but my_error() was called and so, while client got no error, error was logged in binlog.
We now don't call my_error() in this case; we assume the connection know what it does.
This problem was specific to 4.0.21. The change is needed to make replication work with existing versions of innobackup.


sql/lock.cc:
  If a connection has done FLUSH TABLES WITH READ LOCK and now is doing COMMIT, don't give error
  (applies only if it's the same connection; others' COMMITs are still blocked).

1 files changed, 8 insertions, 2 deletions

diff --git a/sql/lock.cc b/sql/lock.cc
index dd2b61b65d2..bf0160291f8 100644
--- a/sql/lock.cc
+++ b/sql/lock.cc
@@ -751,9 +751,15 @@ bool wait_if_global_read_lock(THD *thd, bool abort_on_refresh, bool is_not_commi
   {
     if (thd->global_read_lock)		// This thread had the read locks
     {
-      my_error(ER_CANT_UPDATE_WITH_READLOCK,MYF(0));
+      if (is_not_commit)
+        my_error(ER_CANT_UPDATE_WITH_READLOCK,MYF(0));
       (void) pthread_mutex_unlock(&LOCK_open);
-      DBUG_RETURN(1);
+      /*
+        We allow FLUSHer to COMMIT; we assume FLUSHer knows what it does.
+        This allowance is needed to not break existing versions of innobackup
+        which do a BEGIN; INSERT; FLUSH TABLES WITH READ LOCK; COMMIT.
+      */
+      DBUG_RETURN(is_not_commit);
     }
     old_message=thd->enter_cond(&COND_refresh, &LOCK_open,
 				"Waiting for release of readlock");