Sergei Golubchik 4361c8645b MDEV-136 Non-blocking "set read_only" ...

backport dmitry.shulga@oracle.com-20120209125742-w7hdxv0103ymb8ko from mysql-trunk:

  Patch for bug#11764747 (formerly known as 57612): SET GLOBAL READ_ONLY=1 cannot
  progress when a table is locked with LOCK TABLES.
  
  The reason for the bug was that mysql server makes a flush of all open tables
  during handling of statement 'SET GLOBAL READ_ONLY=1'. Therefore if some of
  these tables were locked by "LOCK TABLE ... READ" from a different connection,
  then execution of statement 'SET GLOBAL READ_ONLY=1' would be waiting for
  the lock for such table even if the table was locked in a compatible read mode.
  
  Flushing of all open tables before setting of read_only system variable
  is inherited from 5.1 implementation since this was the only possible approach
  to ensure that there isn't any pending write operations on open tables.
  
  Start from version 5.5 and above such behaviour is guaranteed by the fact
  that we acquire global_read_lock before setting read_only flag. Since
  acquiring of global_read_lock is successful only when there isn't any 
  active write operation then we can remove flushing of open tables from
  processing of SET GLOBAL READ_ONLY=1.
  
  This modification changes the server behavior so that read locks held
  by other connections (LOCK TABLE ... READ) no longer will block attempts
  to enable read_only.

2012-06-04 17:39:28 +02:00

5.7 KiB

Raw Blame History

View Raw