Vlad Lesin bd03c0e516 MDEV-27025 insert-intention lock conflicts with waiting ORDINARY lock ... When lock is checked for conflict, ignore other locks on the record if they wait for the requesting transaction. lock_rec_has_to_wait_in_queue() iterates not all locks for the page, but only the locks located before the waiting lock in the queue. So there is some invariant - any lock in the queue can wait only lock which is located before the waiting lock in the queue. In the case when conflicting lock waits for the transaction of requesting lock, we need to place the requesting lock before the waiting lock in the queue to preserve the invariant. That is why we are looking for the first waiting for requesting transation lock and place the new lock just after the last granted requesting transaction lock before the first waiting for requesting transaction lock. Example: trx1 waiting lock, trx1 granted lock, ..., trx2 lock - waiting for trx1 place new lock here -----------------^ There are also implicit locks which are lazily converted to explicit ones, and we need to place the newly created explicit lock to the correct place in a queue. All explicit locks converted from implicit ones are placed just after the last non-waiting lock of the same transaction before the first waiting for the transaction lock. Code review and cleanup was made by Marko Mäkelä.		2022-01-18 15:18:42 +03:00
..
lock0iter.cc	MDEV-20612: Replace lock_sys.mutex with lock_sys.latch	2021-02-11 14:52:10 +02:00
lock0lock.cc	MDEV-27025 insert-intention lock conflicts with waiting ORDINARY lock	2022-01-18 15:18:42 +03:00
lock0prdt.cc	MDEV-27058: Reduce the size of buf_block_t and buf_page_t	2021-11-18 17:47:19 +02:00