• sjaakola's avatar
    MDEV-23851 BF-BF Conflict issue because of UK GAP locks · beaea31a
    sjaakola authored
    Some DML operations on tables having unique secondary keys cause scanning
    in the secondary index, for instance to find potential unique key violations
    in the seconday index. This scanning may involve GAP locking in the index.
    As this locking happens also when applying replication events in high priority
    applier threads, there is a probabality for lock conflicts between two wsrep
    high priority threads.
    
    This PR avoids lock conflicts of high priority wsrep threads, which do
    secondary index scanning e.g. for duplicate key detection.
    
    The actual fix is the patch in sql_class.cc:thd_need_ordering_with(), where
    we allow relaxed GAP locking protocol between wsrep high priority threads.
    wsrep high priority threads (replication appliers, replayers and TOI processors)
    are ordered by the replication provider, and they will not need serializability
    support gained by secondary index GAP locks.
    
    PR contains also a mtr test, which exercises a scenario where two replication
    applier threads have a false positive conflict in GAP of unique secondary index.
    The conflicting local committing transaction has to replay, and the test verifies
    also that the replaying phase will not conflict with the latter repllication applier.
    Commit also contains new test scenario for galera.galera_UK_conflict.test,
    where replayer starts applying after a slave applier thread, with later seqno,
    has advanced to commit phase. The applier and replayer have false positive GAP
    lock conflict on secondary unique index, and replayer should ignore this.
    This test scenario caused crash with earlier version in this PR, and to fix this,
    the secondary index uniquenes checking has been relaxed even further.
    
    Now innodb trx_t structure has new member: bool wsrep_UK_scan, which is set to
    true, when high priority thread is performing unique secondary index scanning.
    The member trx_t::wsrep_UK_scan is defined inside WITH_WSREP directive, to make
    it possible to prepare a MariaDB build where this additional trx_t member is
    not present and is not used in the code base. trx->wsrep_UK_scan is set to true
    only for the duration of function call for: lock_rec_lock() trx->wsrep_UK_scan
    is used only in lock_rec_has_to_wait() function to relax the need to wait if
    wsrep_UK_scan is set and conflicting transaction is also high priority.
    Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
    beaea31a
wsrep_thd.cc 27.4 KB