Skip to content
  • Jon Olav Hauglid's avatar
    841a6207
    Fix for bug #14516798 "PREPARE_INPLACE_ALTER_TABLE NOT UNDER EXCLUSIVE · 841a6207
    Jon Olav Hauglid authored
    MDL WHEN LOCK=SHARED".
    
    ALTER TABLE executed using in-place algorithm could trigger an
    InnoDB assertion if during prepare phase of ALTER TABLE, the
    table being altered happened to be used in more than one connection.
    
    The problem was that for types of in-place ALTER TABLE which
    require strong lock during the prepare phase, the SQL-layer acquired
    only SNW metadata lock, thus allowing concurrent reads during
    this phase (as per WL specification). At the same time InnoDB
    assumed that during the prepare phase the table is used only by the
    connection executing ALTER TABLE. This mismatch led to assertion
    failure in InnoDB.
    
    This fix addresses the problem by ensuring that for in-place
    ALTER TABLE variants which require strong lock during the prepare
    phase, the SQL-layer acquires an exclusive (X) metadata lock. To
    support this change we had to add new variant of locking requirements
    for in-place ALTER TABLE - HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE,
    to be used by InnoDB instead of HA_ALTER_INPLACE_SHARED_LOCK
    (since InnoDB requires X lock during prepare phase and the
    latter acquires only SNW lock for both prepare and main phase).
    
    Commit on behalf of Dmitry Lenev.
    841a6207
    Fix for bug #14516798 "PREPARE_INPLACE_ALTER_TABLE NOT UNDER EXCLUSIVE
    Jon Olav Hauglid authored
    MDL WHEN LOCK=SHARED".
    
    ALTER TABLE executed using in-place algorithm could trigger an
    InnoDB assertion if during prepare phase of ALTER TABLE, the
    table being altered happened to be used in more than one connection.
    
    The problem was that for types of in-place ALTER TABLE which
    require strong lock during the prepare phase, the SQL-layer acquired
    only SNW metadata lock, thus allowing concurrent reads during
    this phase (as per WL specification). At the same time InnoDB
    assumed that during the prepare phase the table is used only by the
    connection executing ALTER TABLE. This mismatch led to assertion
    failure in InnoDB.
    
    This fix addresses the problem by ensuring that for in-place
    ALTER TABLE variants which require strong lock during the prepare
    phase, the SQL-layer acquires an exclusive (X) metadata lock. To
    support this change we had to add new variant of locking requirements
    for in-place ALTER TABLE - HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE,
    to be used by InnoDB instead of HA_ALTER_INPLACE_SHARED_LOCK
    (since InnoDB requires X lock during prepare phase and the
    latter acquires only SNW lock for both prepare and main phase).
    
    Commit on behalf of Dmitry Lenev.
Loading