• davi@mysql.com/endora.local's avatar
    Bug#32395 Alter table under a impending global read lock causes a server crash · 137e90ed
    davi@mysql.com/endora.local authored
    The problem is that some DDL statements (ALTER TABLE, CREATE
    TRIGGER, FLUSH TABLES, ...) when under LOCK TABLES need to
    momentarily drop the lock, reopen the table and grab the write
    lock again (using reopen_tables). When grabbing the lock again,
    reopen_tables doesn't pass a flag to mysql_lock_tables in
    order to ignore the impending global read lock, which causes a
    assertion because LOCK_open is being hold. Also dropping the
    lock must not signal to any threads that the table has been
    relinquished (related to the locking/flushing protocol).
    
    The solution is to correct the way the table is reopenned
    and the locks grabbed. When reopening the table and under
    LOCK TABLES, the table version should be set to 0 so other
    threads have to wait for the table. When grabbing the lock,
    any other flush should be ignored because it's theoretically
    a atomic operation. The chosen solution also fixes a potential
    discrepancy between binlog and GRL (global read lock) because
    table placeholders were being ignored, now a FLUSH TABLES WITH
    READ LOCK will properly for table with open placeholders.
    
    It's also important to mention that this patch doesn't fix
    a potential deadlock if one uses two GRLs under LOCK TABLES
    concurrently.
    137e90ed
mysql_priv.h 89.8 KB