• Debarun Banerjee's avatar
    BUG#25082593 FOREIGN KEY VALIDATION DOESN'T NEED TO ACQUIRE GAP LOCK IN READ COMMITTED · 4e41ac26
    Debarun Banerjee authored
    Problem :
    ---------
    This bug is filed from the base replication bug#25040331 where the
    slave thread times out while INSERT operation waits on GAP lock taken
    during Foreign Key validation.
    
    The primary reason for the lock wait is because the statements are
    getting replayed in different order. However, we also observed
    two things ...
    
    1. The slave thread could always use "Read Committed" isolation for
    row level replication.
    
    2. It is not necessary to have GAP locks in "READ Committed" isolation
    level in innodb.
    
    This bug is filed to address point(2) to avoid taking GAP locks during
    Foreign Key validation.
    
    Solution :
    ----------
    Innodb is primarily designed for "Repeatable Read" and the GAP lock
    behaviour is default. For "Read Committed" isolation, we have special
    handling in row_search_mvcc to avoid taking the GAP lock while
    scanning records.
    
    While looking for Foreign Key, the code is following the default
    behaviour taking GAP locks. The suggested fix is to avoid GAP
    locking during FK validation similar to normal search operation
    (row_search_mvcc) for "Read Committed" isolation level.
    Reviewed-by: default avatarSunny Bains <sunny.bains@oracle.com>
    
    RB: 14526
    4e41ac26
row0ins.cc 101 KB