• Sergei Golubchik's avatar
    MDEV-136 Non-blocking "set read_only" · 4361c864
    Sergei Golubchik authored
    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.
    4361c864
read_only.test 6.98 KB