Skip to content
  • Debarun Banerjee's avatar
    423c2ef1
    BUG#27272806 ASSERT DURING REPLICAITON:: LOCK == __NULL · 423c2ef1
    Debarun Banerjee authored
    
    BUG#27294066 INNODB: FAILING ASSERTION: !(TYPE_MODE & 1024)
    
    Problem :
    ---------
    1. We are setting LOCK_REC_NOT_GAP predicate locks also which
    is not meaningful. It is a debug issue.
    
    2. Although supremum record locks are always of type GAP we set
    X/S record lock type to share the same BITMAP with record locks.
    We are setting LOCK_REC_NOT_GAP for supremum in such cases which
    is asserted in some places. It is a debug issue.
    
    Solution :
    ----------
    1. Skip predicate locks while releasing GAP locks
    2. Remove supremum record BIT to release GAP lock on supremum
    3. Add tests to validate the scenario
    
    Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
    
    RB: 18439
    423c2ef1
    BUG#27272806 ASSERT DURING REPLICAITON:: LOCK == __NULL
    Debarun Banerjee authored
    
    BUG#27294066 INNODB: FAILING ASSERTION: !(TYPE_MODE & 1024)
    
    Problem :
    ---------
    1. We are setting LOCK_REC_NOT_GAP predicate locks also which
    is not meaningful. It is a debug issue.
    
    2. Although supremum record locks are always of type GAP we set
    X/S record lock type to share the same BITMAP with record locks.
    We are setting LOCK_REC_NOT_GAP for supremum in such cases which
    is asserted in some places. It is a debug issue.
    
    Solution :
    ----------
    1. Skip predicate locks while releasing GAP locks
    2. Remove supremum record BIT to release GAP lock on supremum
    3. Add tests to validate the scenario
    
    Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
    
    RB: 18439
Loading