Details
Description
We have two transactions and one record. The first transaction holds ORDINARY S-lock on the record, the second transaction created waiting ORDINARY X-lock and waits for the first transaction. Then the first transaction requests insert-intention lock on the record. And this lock conflicts with the waiting ORDINARY X-lock of the second transaction. What causes deadlock. Why it should conflict? The first transaction already holds lock on the record. And the second's transaction lock contains "waiting" flag.
Let's take a look 10.6 code:
dberr_t
|
lock_rec_insert_check_and_lock(...)
|
{
|
...
|
const unsigned type_mode= LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION; |
|
if (lock_t *c_lock= lock_rec_other_has_conflicting(type_mode, |
g.cell(), id,
|
heap_no, trx))
|
{
|
trx->mutex_lock();
|
err= lock_rec_enqueue_waiting(c_lock, type_mode, id, block->frame,
|
heap_no, index, thr, nullptr);
|
trx->mutex_unlock();
|
}
|
...
|
}
|
Neither lock_rec_insert_check_and_lock() nor lock_rec_other_has_conflicting() doesn't check conflicting lock is in waiting state and it already waits for the requesting insert-intention lock transaction.
The test is attached: ii-conflicts-waiting.test
Attachments
Issue Links
- blocks
-
MDEV-10962 Deadlock with 3 concurrent DELETEs by unique key
-
- Closed
-
- causes
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
MDEV-24738 Improve the InnoDB deadlock checker
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- In Progress
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-