Skip to content
  • Jakub Łopuszański's avatar
    fbe2dee2
    Bug #27491839 INNODB: ASSERTION FAILURE: LOCK0LOCK.CC:NNN:!LOCK_REC_OTHER_TRX_HOLDS_EXPL( LOCK · fbe2dee2
    Jakub Łopuszański authored
    
    
    There was a bug in the logic for checking if an active transaction holds an implicit lock on a secondary index when virtual columns were involved.
    In particular, in case when an active transaction happened to not change any of columns of the secondary index it could still be considered to hold an implicit lock.
    
    This patch adds an MTR which reproduces the original issue and covers many other sceanarios.
    It fixes the bug in the logic, at the same time simplifying the code a little.
    
    The patch also provides extensive explanation of what the algorithm does and proof of correctness in comments.
    
    Also, I've updated several places where `const` was missing for a `dict_index_t *index` parameter declaration.
    
    Reviewed-by: default avatarDebarun Banerjee <debarun.banerjee@oracle.com>
    fbe2dee2
    Bug #27491839 INNODB: ASSERTION FAILURE: LOCK0LOCK.CC:NNN:!LOCK_REC_OTHER_TRX_HOLDS_EXPL( LOCK
    Jakub Łopuszański authored
    
    
    There was a bug in the logic for checking if an active transaction holds an implicit lock on a secondary index when virtual columns were involved.
    In particular, in case when an active transaction happened to not change any of columns of the secondary index it could still be considered to hold an implicit lock.
    
    This patch adds an MTR which reproduces the original issue and covers many other sceanarios.
    It fixes the bug in the logic, at the same time simplifying the code a little.
    
    The patch also provides extensive explanation of what the algorithm does and proof of correctness in comments.
    
    Also, I've updated several places where `const` was missing for a `dict_index_t *index` parameter declaration.
    
    Reviewed-by: default avatarDebarun Banerjee <debarun.banerjee@oracle.com>
Loading