(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.
in a deadlock-free manner. This splits locking the global read lock in two steps.
This fixes a consequence of this bug, known as:
BUG#4953 'mysqldump --master-data may report incorrect binlog position if using InnoDB'
And a test.
sql/handler.cc:
making COMMIT wait if FLUSH TABLES WITH READ LOCK happened.
sql/lock.cc:
an additional stage so that FLUSH TABLES WITH READ LOCK blocks COMMIT:
make_global_read_lock_block_commit():
taking the global read lock is TWO steps (2nd step is optional; without
it, COMMIT of existing transactions will be allowed):
lock_global_read_lock() THEN make_global_read_lock_block_commit().
sql/mysql_priv.h:
new argument to wait_if_global_read_lock()
sql/sql_class.h:
THD::global_read_lock now an uint to reflect the 2 steps of global read lock (does not block COMMIT / does)
sql/sql_db.cc:
update for new prototype
sql/sql_parse.cc:
implementing the two steps of global read lock so that FLUSH TABLES WITH READ LOCK can block COMMIT without deadlocking with COMMITs.
