two-line fix for BUG#6732 "FLUSH TABLES WITH READ LOCK + COMMIT makes next FLUSH...LOCK hang forever"

(originally reported as "second run of innobackup hangs forever and can even hang server").
Plus testcase for the bugfix and comments about global read locks.


mysql-test/r/flush_block_commit.result:
  result update
mysql-test/t/flush_block_commit.test:
  testing bugfix (originally: second run of innobackup hangs)
sql/lock.cc:
  When we are in start_waiting_global_read_lock(), if we ourselves have
  the global read lock, there is nothing to start. This makes a pair with how 
  wait_if_global_read_lock() behaves when we ourselves have the global read lock.
  Previously, start_waiting_global_read_lock() decremented protect... whereas wait_if_global_read_lock()
  hadn't incremented it => very wrong => hangs.
  Descriptive comments on how global read lock works.

1 files changed, 14 insertions, 0 deletions

diff --git a/mysql-test/t/flush_block_commit.test b/mysql-test/t/flush_block_commit.test
index 20ecec1361c..8b99a59c979 100644
--- a/mysql-test/t/flush_block_commit.test
+++ b/mysql-test/t/flush_block_commit.test
@@ -45,5 +45,19 @@ reap;
 connection con3;
 reap;
 unlock tables;
+
+# BUG#6732 FLUSH TABLES WITH READ LOCK + COMMIT hangs later FLUSH TABLES
+# WITH READ LOCK
+
+connection con2;
+commit; # unlock InnoDB row locks to allow insertions
 connection con1;
+begin;
+insert into t1 values(10);
+flush tables with read lock;
+commit;
+unlock tables;
+connection con2;
+flush tables with read lock; # bug caused hang here
+unlock tables;
 drop table t1;