• Dmitry Lenev's avatar
    Fix for bug #45143 "All connections hang on concurrent ALTER TABLE". · 86c23fa7
    Dmitry Lenev authored
    Concurrent execution of statements which require non-table-level
    write locks on several instances of the same table (such as
    SELECT ... FOR UPDATE which uses same InnoDB table twice or a DML
    statement which invokes trigger which tries to update same InnoDB
    table directly and through stored function) and statements which
    required table-level locks on this table (e.g. LOCK TABLE ... WRITE,
    ALTER TABLE, ...) might have resulted in a deadlock.
    
    The problem occured when a thread tried to acquire write lock
    (TL_WRITE_ALLOW_WRITE) on the table but had to wait since there was
    a pending write lock (TL_WRITE, TL_WRITE_ALLOW_READ) on this table
    and we failed to detect that this thread already had another instance
    of write lock on it (so in fact we were trying to acquire recursive
    lock) because there was also another thread holding write lock on the
    table (also TL_WRITE_ALLOW_WRITE). When the latter thread released
    its lock neither the first thread nor the thread trying to acquire
    TL_WRITE/TL_WRITE_ALLOW_READ were woken up (as table was still write
    locked by the first thread) so we ended up with a deadlock.
    
    This patch solves this problem by ensuring that thread which
    already has write lock on the table won't wait when it tries
    to acquire second write lock on the same table.
    
    mysql-test/r/lock_sync.result:
      Added test case for bug #45143 "All connections hang on concurrent
      ALTER TABLE".
    mysql-test/t/lock_sync.test:
      Added test case for bug #45143 "All connections hang on concurrent
      ALTER TABLE".
    mysys/thr_lock.c:
      Ensured that thread can acquire write lock on the table without
      waiting if it already has write lock on it even if there are other
      threads holding write locks on this table (this is normal situation
      for, e.g., TL_WRITE_ALLOW_WRITE type of lock).
      
      Adjusted comments to better explain why it is OK to do so and added
      asserts to prevent introduction of scenarios in which this can cause
      problems.
    86c23fa7
lock_sync.test 4.41 KB