[MDEV-27025] insert-intention lock conflicts with waiting ORDINARY lock - Jira

Vladislav Lesin created issue - 2021-11-11 10:38

Vladislav Lesin made changes - 2021-11-11 10:40

Field	Original Value	New Value
Link		This issue relates to ~~MDEV-20605~~ [ ~~MDEV-20605~~ ]

Vladislav Lesin made changes - 2021-11-11 10:41

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 stronger lock, then the second transaction. And the second's transaction lock contains "waiting" flag.

The test is attached: [^ii-conflicts-waiting.test]

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 stronger lock, then the second transaction. And the second's transaction lock contains "waiting" flag.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

Vladislav Lesin made changes - 2021-11-11 10:58

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 stronger lock, then the second transaction. And the second's transaction lock contains "waiting" flag.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

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 stronger lock, then the second transaction. And the second's transaction lock contains "waiting" flag.

Let's take a look 10.6 code:

{code:java}
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();
      }
...
}
{code}

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.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

Vladislav Lesin made changes - 2021-11-11 10:58

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 stronger lock, then the second transaction. And the second's transaction lock contains "waiting" flag.

Let's take a look 10.6 code:

{code:java}
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();
      }
...
}
{code}

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.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

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 stronger lock, then the second transaction. And the second's transaction lock contains "waiting" flag.

Let's take a look 10.6 code:

{code:java}
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();
      }
...
}
{code}

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.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

Marko Mäkelä made changes - 2021-11-11 11:34

Summary

insert-intetion lock conflicts with waiting ORDINARY lock

insert-intention lock conflicts with waiting ORDINARY lock

Vladislav Lesin made changes - 2021-11-11 13:23

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 stronger lock, then the second transaction. And the second's transaction lock contains "waiting" flag.

Let's take a look 10.6 code:

{code:java}
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();
      }
...
}
{code}

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.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

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:

{code:java}
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();
      }
...
}
{code}

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.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

Valerii Kravchuk added a comment - 2021-11-11 17:16

See also https://bugs.mysql.com/bug.php?id=21356

Valerii Kravchuk added a comment - 2021-11-11 17:16 See also https://bugs.mysql.com/bug.php?id=21356

Vladislav Lesin made changes - 2021-12-02 10:03

Affects Version/s		10.2 [ 14601 ]
Affects Version/s		10.3 [ 22126 ]
Affects Version/s		10.4 [ 22408 ]
Affects Version/s		10.5 [ 23123 ]

Vladislav Lesin made changes - 2021-12-02 10:04

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:

{code:java}
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();
      }
...
}
{code}

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.

I have not yet checked versions less then 10.6.

The test is attached: [^ii-conflicts-waiting.test]

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:

{code:java}
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();
      }
...
}
{code}

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]

Vladislav Lesin made changes - 2021-12-02 10:07

Fix Version/s		10.2 [ 14601 ]
Fix Version/s		10.3 [ 22126 ]
Fix Version/s		10.4 [ 22408 ]
Fix Version/s		10.5 [ 23123 ]
Fix Version/s		10.6 [ 24028 ]
Fix Version/s		10.7 [ 24805 ]
Fix Version/s		10.8 [ 26121 ]

Vladislav Lesin made changes - 2021-12-02 10:07

Status

Open [ 1 ]

In Progress [ 3 ]

Julien Fritsch made changes - 2021-12-06 08:39

Priority

Major [ 3 ]

Critical [ 2 ]

Sergei Golubchik made changes - 2021-12-06 21:36

Workflow

MariaDB v3 [ 127341 ]

MariaDB v4 [ 144616 ]

Matthias Leich added a comment - 2021-12-14 16:05 - edited

Non rare problem observed during RQG testing.

sdp:/data/results/1639496318/TBR-1300/dev/shm/rqg/1639496318/112/1/rr

(rr) bt

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

#1  0x00007f0ae1e11859 in __GI_abort () at abort.c:79

#2  0x00007f0ae1e11729 in __assert_fail_base (fmt=0x7f0ae1fa7588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55ef2ea609e0 "lock_rec_has_expl(LOCK_X | 1024U, cell, id, heap_no, impl_trx)",

    file=0x55ef2ea59580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4676, function=<optimized out>) at assert.c:92

#3  0x00007f0ae1e22f36 in __GI___assert_fail (assertion=0x55ef2ea609e0 "lock_rec_has_expl(LOCK_X | 1024U, cell, id, heap_no, impl_trx)", file=0x55ef2ea59580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4676,

    function=0x55ef2ea605e0 "bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*)") at assert.c:101

#4  0x000055ef2d6eafc5 in lock_rec_queue_validate (locked_lock_trx_sys=false, id=..., rec=0x7f0ad5ab0369 "\200", index=0x6160070ec708, offsets=0x7f0abf5108c0) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4676

#5  0x000055ef2d6edf25 in lock_rec_insert_check_and_lock (rec=0x7f0ad5ab0143 "\200", block=0x7f0ad470ed70, index=0x6160070ec708, thr=0x620000326868, mtr=0x7f0abf511a70, inherit=0x7f0abf510e50)

    at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:5034

#6  0x000055ef2dab9ae8 in btr_cur_ins_lock_and_undo (flags=0, cursor=0x7f0abf511660, entry=0x616006f75408, thr=0x620000326868, mtr=0x7f0abf511a70, inherit=0x7f0abf510e50) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/btr/btr0cur.cc:3271

#7  0x000055ef2dabb3fd in btr_cur_optimistic_insert (flags=0, cursor=0x7f0abf511660, offsets=0x7f0abf511620, heap=0x7f0abf511600, entry=0x616006f75408, rec=0x7f0abf511640, big_rec=0x7f0abf5115e0, n_ext=0, thr=0x620000326868, mtr=0x7f0abf511a70)

    at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/btr/btr0cur.cc:3515

#8  0x000055ef2d8a1590 in row_ins_clust_index_entry_low (flags=0, mode=2, index=0x6160070ec708, n_uniq=1, entry=0x616006f75408, n_ext=0, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:2759

#9  0x000055ef2d8a3cf2 in row_ins_clust_index_entry (index=0x6160070ec708, entry=0x616006f75408, thr=0x620000326868, n_ext=0) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3230

#10 0x000055ef2d8a45f1 in row_ins_index_entry (index=0x6160070ec708, entry=0x616006f75408, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3356

#11 0x000055ef2d8a5661 in row_ins_index_entry_step (node=0x620000326630, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3524

#12 0x000055ef2d8a6020 in row_ins (node=0x620000326630, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3670

#13 0x000055ef2d8a7148 in row_ins_step (thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3816

#14 0x000055ef2d8e62e3 in row_insert_for_mysql (mysql_rec=0x6190005884d0 "\377\001", prebuilt=0x620000326108, ins_mode=ROW_INS_NORMAL) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0mysql.cc:1318

#15 0x000055ef2d55dd15 in ha_innobase::write_row (this=0x61d0014866b8, record=0x6190005884d0 "\377\001") at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:7836

#16 0x000055ef2cc8cc86 in handler::ha_write_row (this=0x61d0014866b8, buf=0x6190005884d0 "\377\001") at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/handler.cc:7519

#17 0x000055ef2c3e1820 in write_record (thd=0x62b00016c218, table=0x619000587f98, info=0x7f0abf512e60, sink=0x0) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_insert.cc:2146

#18 0x000055ef2c3d9fd9 in mysql_insert (thd=0x62b00016c218, table_list=0x62b0001733b0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false, result=0x0) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_insert.cc:1123

#19 0x000055ef2c4971a3 in mysql_execute_command (thd=0x62b00016c218, is_called_from_prepared_stmt=false) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:4565

#20 0x000055ef2c4ae54a in mysql_parse (thd=0x62b00016c218, rawbuf=0x62b000173238 "INSERT INTO unrelated (a) VALUES ( 1) /* E_R Thread8 QNO 93 CON_ID 22 */", length=72, parser_state=0x7f0abf513b20) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:8030

#21 0x000055ef2c4867c1 in dispatch_command (command=COM_QUERY, thd=0x62b00016c218, packet=0x629000c8f219 "INSERT INTO unrelated (a) VALUES ( 1) /* E_R Thread8 QNO 93 CON_ID 22 */ ", packet_length=73, blocking=true)

    at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1896

#22 0x000055ef2c483b99 in do_command (thd=0x62b00016c218, blocking=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1404

#23 0x000055ef2c883cfc in do_handle_one_connection (connect=0x608000003338, put_in_cache=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1418

#24 0x000055ef2c883588 in handle_one_connection (arg=0x608000003338) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1312

#25 0x00007f0ae2339609 in start_thread (arg=<optimized out>) at pthread_create.c:477

#26 0x00007f0ae1f0e293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(rr)

mysqld: /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4676: bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*): Assertion `lock_rec_has_expl(LOCK_X | 1024U, cell, id, heap_no, impl_trx)' failed.

for some INSERT INTO unrelated (a) VALUES ( 1)

Status: NOT_KILLED

sdp:/data/results/1639496318/TBR-1301/dev/shm/rqg/1639496318/38/1/rr

(rr) bt

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

#1  0x00007fa520f7d859 in __GI_abort () at abort.c:79

#2  0x00007fa520f7d729 in __assert_fail_base (fmt=0x7fa521113588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x559bd2c76c40 "!other_lock", file=0x559bd2c74580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4721,

    function=<optimized out>) at assert.c:92

#3  0x00007fa520f8ef36 in __GI___assert_fail (assertion=0x559bd2c76c40 "!other_lock", file=0x559bd2c74580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4721,

    function=0x559bd2c7b5e0 "bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*)") at assert.c:101

#4  0x0000559bd1906680 in lock_rec_queue_validate (locked_lock_trx_sys=false, id=..., rec=0x77414acd02c4 "\200", index=0x616005566f08, offsets=0x655873840a70) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4721

#5  0x0000559bd190ca0c in lock_clust_rec_read_check_and_lock (flags=0, block=0x774149e77e50, rec=0x77414acd02c4 "\200", index=0x616005566f08, offsets=0x655873840a70, mode=LOCK_X, gap_mode=0, thr=0x62100015ea10)

    at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:5532

#6  0x0000559bd1b68de9 in sel_set_rec_lock (pcur=0x62100015e368, rec=0x77414acd02c4 "\200", index=0x616005566f08, offsets=0x655873840a70, mode=3, type=0, thr=0x62100015ea10, mtr=0x655873840d50)

    at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0sel.cc:1326

#7  0x0000559bd1b7f270 in row_search_mvcc (buf=0x61a00011d6b8 "\377\377", mode=PAGE_CUR_G, prebuilt=0x62100015e188, match_mode=0, direction=0) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0sel.cc:5186

#8  0x0000559bd177f0cb in ha_innobase::index_read (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:9016

#9  0x0000559bd1781a48 in ha_innobase::index_first (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377") at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:9377

#10 0x0000559bd1781c86 in ha_innobase::rnd_next (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377") at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:9470

#11 0x0000559bd0e8ae3c in handler::ha_rnd_next (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377") at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/handler.cc:3396

#12 0x0000559bd1294667 in rr_sequential (info=0x655873841710) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/records.cc:519

#13 0x0000559bd051ab26 in READ_RECORD::read_record (this=0x655873841710) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/records.h:81

#14 0x0000559bd12e1a87 in mysql_delete (thd=0x62b00012d218, table_list=0x62b0001343b8, conds=0x62b000135088, order_list=0x62b000131e60, limit=18446744073709551615, options=0, result=0x0) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_delete.cc:796

#15 0x0000559bd06b4680 in mysql_execute_command (thd=0x62b00012d218, is_called_from_prepared_stmt=false) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:4807

#16 0x0000559bd06c954a in mysql_parse (thd=0x62b00012d218, rawbuf=0x62b000134238 "DELETE FROM t6 WHERE col2 = 16 OR col2 IS NULL  /* E_R Thread2 QNO 11207 CON_ID 55 */", length=85, parser_state=0x655873842b20)

    at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:8030

#17 0x0000559bd06a17c1 in dispatch_command (command=COM_QUERY, thd=0x62b00012d218, packet=0x629006095219 " DELETE FROM t6 WHERE col2 = 16 OR col2 IS NULL  /* E_R Thread2 QNO 11207 CON_ID 55 */ ", packet_length=87, blocking=true)

    at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1896

#18 0x0000559bd069eb99 in do_command (thd=0x62b00012d218, blocking=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1404

#19 0x0000559bd0a9ecfc in do_handle_one_connection (connect=0x608000038738, put_in_cache=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1418

#20 0x0000559bd0a9e588 in handle_one_connection (arg=0x608000003038) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1312

#21 0x00007fa521174609 in start_thread (arg=<optimized out>) at pthread_create.c:477

#22 0x00007fa52107a293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(rr)

mysqld: /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4721: bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*): Assertion `!other_lock' failed.

for some DELETE FROM t6 WHERE col2 = 16 OR col2 IS NULL

Status: KILL_TIMEOUT

Matthias Leich added a comment - 2021-12-14 16:05 - edited Non rare problem observed during RQG testing. sdp:/data/results/1639496318/TBR-1300/dev/shm/rqg/1639496318/112/1/rr (rr) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f0ae1e11859 in __GI_abort () at abort.c:79 #2 0x00007f0ae1e11729 in __assert_fail_base (fmt=0x7f0ae1fa7588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55ef2ea609e0 "lock_rec_has_expl(LOCK_X | 1024U, cell, id, heap_no, impl_trx)", file=0x55ef2ea59580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4676, function=<optimized out>) at assert.c:92 #3 0x00007f0ae1e22f36 in __GI___assert_fail (assertion=0x55ef2ea609e0 "lock_rec_has_expl(LOCK_X | 1024U, cell, id, heap_no, impl_trx)", file=0x55ef2ea59580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4676, function=0x55ef2ea605e0 "bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*)") at assert.c:101 #4 0x000055ef2d6eafc5 in lock_rec_queue_validate (locked_lock_trx_sys=false, id=..., rec=0x7f0ad5ab0369 "\200", index=0x6160070ec708, offsets=0x7f0abf5108c0) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4676 #5 0x000055ef2d6edf25 in lock_rec_insert_check_and_lock (rec=0x7f0ad5ab0143 "\200", block=0x7f0ad470ed70, index=0x6160070ec708, thr=0x620000326868, mtr=0x7f0abf511a70, inherit=0x7f0abf510e50) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:5034 #6 0x000055ef2dab9ae8 in btr_cur_ins_lock_and_undo (flags=0, cursor=0x7f0abf511660, entry=0x616006f75408, thr=0x620000326868, mtr=0x7f0abf511a70, inherit=0x7f0abf510e50) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/btr/btr0cur.cc:3271 #7 0x000055ef2dabb3fd in btr_cur_optimistic_insert (flags=0, cursor=0x7f0abf511660, offsets=0x7f0abf511620, heap=0x7f0abf511600, entry=0x616006f75408, rec=0x7f0abf511640, big_rec=0x7f0abf5115e0, n_ext=0, thr=0x620000326868, mtr=0x7f0abf511a70) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/btr/btr0cur.cc:3515 #8 0x000055ef2d8a1590 in row_ins_clust_index_entry_low (flags=0, mode=2, index=0x6160070ec708, n_uniq=1, entry=0x616006f75408, n_ext=0, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:2759 #9 0x000055ef2d8a3cf2 in row_ins_clust_index_entry (index=0x6160070ec708, entry=0x616006f75408, thr=0x620000326868, n_ext=0) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3230 #10 0x000055ef2d8a45f1 in row_ins_index_entry (index=0x6160070ec708, entry=0x616006f75408, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3356 #11 0x000055ef2d8a5661 in row_ins_index_entry_step (node=0x620000326630, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3524 #12 0x000055ef2d8a6020 in row_ins (node=0x620000326630, thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3670 #13 0x000055ef2d8a7148 in row_ins_step (thr=0x620000326868) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0ins.cc:3816 #14 0x000055ef2d8e62e3 in row_insert_for_mysql (mysql_rec=0x6190005884d0 "\377\001", prebuilt=0x620000326108, ins_mode=ROW_INS_NORMAL) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0mysql.cc:1318 #15 0x000055ef2d55dd15 in ha_innobase::write_row (this=0x61d0014866b8, record=0x6190005884d0 "\377\001") at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:7836 #16 0x000055ef2cc8cc86 in handler::ha_write_row (this=0x61d0014866b8, buf=0x6190005884d0 "\377\001") at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/handler.cc:7519 #17 0x000055ef2c3e1820 in write_record (thd=0x62b00016c218, table=0x619000587f98, info=0x7f0abf512e60, sink=0x0) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_insert.cc:2146 #18 0x000055ef2c3d9fd9 in mysql_insert (thd=0x62b00016c218, table_list=0x62b0001733b0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false, result=0x0) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_insert.cc:1123 #19 0x000055ef2c4971a3 in mysql_execute_command (thd=0x62b00016c218, is_called_from_prepared_stmt=false) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:4565 #20 0x000055ef2c4ae54a in mysql_parse (thd=0x62b00016c218, rawbuf=0x62b000173238 "INSERT INTO unrelated (a) VALUES ( 1) /* E_R Thread8 QNO 93 CON_ID 22 */", length=72, parser_state=0x7f0abf513b20) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:8030 #21 0x000055ef2c4867c1 in dispatch_command (command=COM_QUERY, thd=0x62b00016c218, packet=0x629000c8f219 "INSERT INTO unrelated (a) VALUES ( 1) /* E_R Thread8 QNO 93 CON_ID 22 */ ", packet_length=73, blocking=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1896 #22 0x000055ef2c483b99 in do_command (thd=0x62b00016c218, blocking=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1404 #23 0x000055ef2c883cfc in do_handle_one_connection (connect=0x608000003338, put_in_cache=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1418 #24 0x000055ef2c883588 in handle_one_connection (arg=0x608000003338) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1312 #25 0x00007f0ae2339609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #26 0x00007f0ae1f0e293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (rr) mysqld: /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4676: bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*): Assertion `lock_rec_has_expl(LOCK_X | 1024U, cell, id, heap_no, impl_trx)' failed. for some INSERT INTO unrelated (a) VALUES ( 1) Status: NOT_KILLED sdp:/data/results/1639496318/TBR-1301/dev/shm/rqg/1639496318/38/1/rr (rr) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007fa520f7d859 in __GI_abort () at abort.c:79 #2 0x00007fa520f7d729 in __assert_fail_base (fmt=0x7fa521113588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x559bd2c76c40 "!other_lock", file=0x559bd2c74580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4721, function=<optimized out>) at assert.c:92 #3 0x00007fa520f8ef36 in __GI___assert_fail (assertion=0x559bd2c76c40 "!other_lock", file=0x559bd2c74580 "/data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc", line=4721, function=0x559bd2c7b5e0 "bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*)") at assert.c:101 #4 0x0000559bd1906680 in lock_rec_queue_validate (locked_lock_trx_sys=false, id=..., rec=0x77414acd02c4 "\200", index=0x616005566f08, offsets=0x655873840a70) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4721 #5 0x0000559bd190ca0c in lock_clust_rec_read_check_and_lock (flags=0, block=0x774149e77e50, rec=0x77414acd02c4 "\200", index=0x616005566f08, offsets=0x655873840a70, mode=LOCK_X, gap_mode=0, thr=0x62100015ea10) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:5532 #6 0x0000559bd1b68de9 in sel_set_rec_lock (pcur=0x62100015e368, rec=0x77414acd02c4 "\200", index=0x616005566f08, offsets=0x655873840a70, mode=3, type=0, thr=0x62100015ea10, mtr=0x655873840d50) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0sel.cc:1326 #7 0x0000559bd1b7f270 in row_search_mvcc (buf=0x61a00011d6b8 "\377\377", mode=PAGE_CUR_G, prebuilt=0x62100015e188, match_mode=0, direction=0) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/row/row0sel.cc:5186 #8 0x0000559bd177f0cb in ha_innobase::index_read (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:9016 #9 0x0000559bd1781a48 in ha_innobase::index_first (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377") at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:9377 #10 0x0000559bd1781c86 in ha_innobase::rnd_next (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377") at /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/handler/ha_innodb.cc:9470 #11 0x0000559bd0e8ae3c in handler::ha_rnd_next (this=0x61d000e664b8, buf=0x61a00011d6b8 "\377\377") at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/handler.cc:3396 #12 0x0000559bd1294667 in rr_sequential (info=0x655873841710) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/records.cc:519 #13 0x0000559bd051ab26 in READ_RECORD::read_record (this=0x655873841710) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/records.h:81 #14 0x0000559bd12e1a87 in mysql_delete (thd=0x62b00012d218, table_list=0x62b0001343b8, conds=0x62b000135088, order_list=0x62b000131e60, limit=18446744073709551615, options=0, result=0x0) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_delete.cc:796 #15 0x0000559bd06b4680 in mysql_execute_command (thd=0x62b00012d218, is_called_from_prepared_stmt=false) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:4807 #16 0x0000559bd06c954a in mysql_parse (thd=0x62b00012d218, rawbuf=0x62b000134238 "DELETE FROM t6 WHERE col2 = 16 OR col2 IS NULL /* E_R Thread2 QNO 11207 CON_ID 55 */", length=85, parser_state=0x655873842b20) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:8030 #17 0x0000559bd06a17c1 in dispatch_command (command=COM_QUERY, thd=0x62b00012d218, packet=0x629006095219 " DELETE FROM t6 WHERE col2 = 16 OR col2 IS NULL /* E_R Thread2 QNO 11207 CON_ID 55 */ ", packet_length=87, blocking=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1896 #18 0x0000559bd069eb99 in do_command (thd=0x62b00012d218, blocking=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_parse.cc:1404 #19 0x0000559bd0a9ecfc in do_handle_one_connection (connect=0x608000038738, put_in_cache=true) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1418 #20 0x0000559bd0a9e588 in handle_one_connection (arg=0x608000003038) at /data/Server/bb-10.6-MDEV-27025-deadlock/sql/sql_connect.cc:1312 #21 0x00007fa521174609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #22 0x00007fa52107a293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (rr) mysqld: /data/Server/bb-10.6-MDEV-27025-deadlock/storage/innobase/lock/lock0lock.cc:4721: bool lock_rec_queue_validate(bool, page_id_t, const rec_t*, const dict_index_t*, const rec_offs*): Assertion `!other_lock' failed. for some DELETE FROM t6 WHERE col2 = 16 OR col2 IS NULL Status: KILL_TIMEOUT

Vladislav Lesin made changes - 2021-12-27 23:55

Comment

[ A comment with security level 'Developers' was removed. ]

Vladislav Lesin added a comment - 2021-12-28 00:13 - edited

Some update. During fixing the above bugs I found out that the initial fix is wrong. We need to preserve the invariant that any lock in locks queue can wait only the lock which is located before the waiting lock in the queue. I added the corresponding code, but RQG testing showed one more crash, which I have not fixed yet. See commit message for details (https://github.com/MariaDB/server/tree/bb-10.6-MDEV-27025-deadlock).

Vladislav Lesin added a comment - 2021-12-28 00:13 - edited Some update. During fixing the above bugs I found out that the initial fix is wrong. We need to preserve the invariant that any lock in locks queue can wait only the lock which is located before the waiting lock in the queue. I added the corresponding code, but RQG testing showed one more crash, which I have not fixed yet. See commit message for details ( https://github.com/MariaDB/server/tree/bb-10.6-MDEV-27025-deadlock ).

Vladislav Lesin added a comment - 2021-12-30 19:56

Update. I got rid of SEGFAULT mentioned the previous comment, but RQG testing still shows the case when there are two granted conflicting locks on the same record. It still happens during "XA prepare" when all S-locks of the XA are released and X-lock of the other transaction is granted because it is located before the conflicting XA X-lock in the queue despite that XA X-lock was created before the granted X-lock of the other transaction. So the question is how such order of locks in the queue is possible. Still debugging it.

Vladislav Lesin added a comment - 2021-12-30 19:56 Update. I got rid of SEGFAULT mentioned the previous comment, but RQG testing still shows the case when there are two granted conflicting locks on the same record. It still happens during "XA prepare" when all S-locks of the XA are released and X-lock of the other transaction is granted because it is located before the conflicting XA X-lock in the queue despite that XA X-lock was created before the granted X-lock of the other transaction. So the question is how such order of locks in the queue is possible. Still debugging it.

Vladislav Lesin added a comment - 2022-01-03 14:26

Update. I have fixed the above error. Matthias created special RQG config file to cause the above bugs, local RQG testing of my fix with this file contains no above errors. I pushed my branch for buildbot testing and in parallel launched local RQG testing with InnoDB_standard.cc config.

Vladislav Lesin added a comment - 2022-01-03 14:26 Update. I have fixed the above error. Matthias created special RQG config file to cause the above bugs, local RQG testing of my fix with this file contains no above errors. I pushed my branch for buildbot testing and in parallel launched local RQG testing with InnoDB_standard.cc config.

Marko Mäkelä made changes - 2022-01-04 09:54

Link

This issue blocks ~~MDEV-10962~~ [ ~~MDEV-10962~~ ]

Marko Mäkelä made changes - 2022-01-04 13:08

Status

In Progress [ 3 ]

In Testing [ 10301 ]

Marko Mäkelä added a comment - 2022-01-04 13:16

This is great work. I cannot see anything obviously wrong in the logic. I pushed some suggested cleanup. If you agree and tests pass, it should be eventually merged to the final commit.

mleich, please test this extensively with RQG. Unfortunately, we had to relax a debug assertion in lock_rec_queue_validate() due to the improved conflict handling. Instead of asserting that the conflicting lock is exclusive, we assert that it must be at least shared.

Marko Mäkelä added a comment - 2022-01-04 13:16 This is great work. I cannot see anything obviously wrong in the logic. I pushed some suggested cleanup . If you agree and tests pass, it should be eventually merged to the final commit. mleich , please test this extensively with RQG. Unfortunately, we had to relax a debug assertion in lock_rec_queue_validate() due to the improved conflict handling. Instead of asserting that the conflicting lock is exclusive, we assert that it must be at least shared.

Marko Mäkelä made changes - 2022-01-04 13:16

Assignee

Vladislav Lesin [ vlad.lesin ]

Matthias Leich [ mleich ]

Matthias Leich added a comment - 2022-01-06 15:52

origin/bb-10.6-~~MDEV-27025~~-deadlock 4eaea8c5032b9040394bc4138d28c0cb9e29caab 2022-01-04T15:01:42+02:00
behaved well in RQG testing. Failing tests are either caused by bad effects known from other branches too
or weaknesses in RQG.

Matthias Leich added a comment - 2022-01-06 15:52 origin/bb-10.6- MDEV-27025 -deadlock 4eaea8c5032b9040394bc4138d28c0cb9e29caab 2022-01-04T15:01:42+02:00 behaved well in RQG testing. Failing tests are either caused by bad effects known from other branches too or weaknesses in RQG.

Matthias Leich made changes - 2022-01-06 15:53

Status

In Testing [ 10301 ]

Stalled [ 10000 ]

Matthias Leich made changes - 2022-01-06 15:54

Assignee

Matthias Leich [ mleich ]

Vladislav Lesin [ vlad.lesin ]

Vladislav Lesin made changes - 2022-01-10 10:39

Link

This issue relates to ~~MDEV-24738~~ [ ~~MDEV-24738~~ ]

Sergei Golubchik added a comment - 2022-01-10 11:47

I think it has to be backported. At least to 10.5

Sergei Golubchik added a comment - 2022-01-10 11:47 I think it has to be backported. At least to 10.5

Vladislav Lesin added a comment - 2022-01-10 16:21 - edited

Update: I have started trx_lock_t::wait_trx backporting to 10.5. I have also ported some debug checks, some of them fail on mtr tests due to wrong trx_lock_t::wait_trx reset. 10.5 and 10.6 locking code differs. As an example, in 10.5 lock_rec_move_low() invokes lock_reset_lock_and_trx_wait() before lock_rec_add_to_queue(). lock_reset_lock_and_trx_wait() resets trx_lock_t::wait_trx, what causes assertion failure in lock_rec_add_to_queue(). 10.6 does not invoke lock_reset_lock_and_trx_wait() from lock_rec_move(), it just does necessary actions inline instead. So I need to catch all such errors.

Vladislav Lesin added a comment - 2022-01-10 16:21 - edited Update: I have started trx_lock_t::wait_trx backporting to 10.5. I have also ported some debug checks, some of them fail on mtr tests due to wrong trx_lock_t::wait_trx reset. 10.5 and 10.6 locking code differs. As an example, in 10.5 lock_rec_move_low() invokes lock_reset_lock_and_trx_wait() before lock_rec_add_to_queue(). lock_reset_lock_and_trx_wait() resets trx_lock_t::wait_trx, what causes assertion failure in lock_rec_add_to_queue(). 10.6 does not invoke lock_reset_lock_and_trx_wait() from lock_rec_move(), it just does necessary actions inline instead. So I need to catch all such errors.

Vladislav Lesin made changes - 2022-01-11 14:36

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Vladislav Lesin added a comment - 2022-01-11 21:33

Update: backported trx_lock_t::wait_trx and the fix to 10.5(branch bb-10.5-~~MDEV-27025~~-deadlock). The branch is not fully tested, code cleanup and review are necessary after RQG testing.

Vladislav Lesin added a comment - 2022-01-11 21:33 Update: backported trx_lock_t::wait_trx and the fix to 10.5(branch bb-10.5- MDEV-27025 -deadlock). The branch is not fully tested, code cleanup and review are necessary after RQG testing.

Vladislav Lesin added a comment - 2022-01-12 18:20

Update: did some code cleanup, fixed embedded server compilation error caused by my changes, did some code research to make sure my changes will not break Galera cluster and innodb-lock-schedule-algorithm=VATS,, passed the branch for RQG testing. My local RQG testing have not finished yet, but it looks promising, at least I don't see any crashes during several hours.

Vladislav Lesin added a comment - 2022-01-12 18:20 Update: did some code cleanup, fixed embedded server compilation error caused by my changes, did some code research to make sure my changes will not break Galera cluster and innodb-lock-schedule-algorithm=VATS,, passed the branch for RQG testing. My local RQG testing have not finished yet, but it looks promising, at least I don't see any crashes during several hours.

Vladislav Lesin made changes - 2022-01-12 18:22

Status

In Progress [ 3 ]

In Testing [ 10301 ]

Vladislav Lesin made changes - 2022-01-12 18:22

Assignee

Vladislav Lesin [ vlad.lesin ]

Matthias Leich [ mleich ]

Matthias Leich added a comment - 2022-01-13 12:37

origin/bb-10.5-~~MDEV-27025~~-deadlock 1519b9a7aa774a6b728e29f107c16b6d713ce647 2022-01-12T19:32:22+03:00
behaved well in RQG testing. Bad effects observed occur also on actual MariaDB versions.

Matthias Leich added a comment - 2022-01-13 12:37 origin/bb-10.5- MDEV-27025 -deadlock 1519b9a7aa774a6b728e29f107c16b6d713ce647 2022-01-12T19:32:22+03:00 behaved well in RQG testing. Bad effects observed occur also on actual MariaDB versions.

Matthias Leich made changes - 2022-01-13 12:38

Assignee	Matthias Leich [ mleich ]	Vladislav Lesin [ vlad.lesin ]
Status	In Testing [ 10301 ]	Stalled [ 10000 ]

Vladislav Lesin added a comment - 2022-01-13 21:53

I squashed the commits and rebased the branches. In 10.6 branch I added some details in the comment to clarify why we don't need to lock lock_sys.wait_mutex to check trx->lock.wait_trx. marko, you have already reviewed 10.6 branch, could you please also review 10.5 branch?

Vladislav Lesin added a comment - 2022-01-13 21:53 I squashed the commits and rebased the branches. In 10.6 branch I added some details in the comment to clarify why we don't need to lock lock_sys.wait_mutex to check trx->lock.wait_trx. marko , you have already reviewed 10.6 branch, could you please also review 10.5 branch?

Vladislav Lesin made changes - 2022-01-13 21:54

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Vladislav Lesin added a comment - 2022-01-13 21:55

bb-10.5-~~MDEV-27025~~-deadlock branch needs review.

Vladislav Lesin added a comment - 2022-01-13 21:55 bb-10.5- MDEV-27025 -deadlock branch needs review.

Vladislav Lesin made changes - 2022-01-13 21:55

Assignee	Vladislav Lesin [ vlad.lesin ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Marko Mäkelä added a comment - 2022-01-14 07:17

The 10.6 version has already been reviewed and tested. That one is OK to push.

Backporting to earlier versions is tricky and potentially risky, because the locking subsystem was heavily refactored in the 10.6 release.

I posted some minor comments to the 10.5 version. I did not find anything really wrong there. I think that we’d better wait for additional test results from our customer before pushing the 10.5 version.

Marko Mäkelä added a comment - 2022-01-14 07:17 The 10.6 version has already been reviewed and tested. That one is OK to push. Backporting to earlier versions is tricky and potentially risky, because the locking subsystem was heavily refactored in the 10.6 release. I posted some minor comments to the 10.5 version. I did not find anything really wrong there. I think that we’d better wait for additional test results from our customer before pushing the 10.5 version.

Marko Mäkelä made changes - 2022-01-14 07:18

Assignee	Marko Mäkelä [ marko ]	Vladislav Lesin [ vlad.lesin ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Jan Lindström (Inactive) made changes - 2022-01-14 10:04

Link

This issue causes TODO-3312 [ TODO-3312 ]

Vladislav Lesin made changes - 2022-01-19 09:28

Fix Version/s		10.5.14 [ 26809 ]
Fix Version/s		10.6.6 [ 26811 ]
Fix Version/s		10.7.2 [ 26813 ]
Fix Version/s		10.8.1 [ 26815 ]
Fix Version/s	10.2 [ 14601 ]
Fix Version/s	10.3 [ 22126 ]
Fix Version/s	10.4 [ 22408 ]
Fix Version/s	10.5 [ 23123 ]
Fix Version/s	10.6 [ 24028 ]
Fix Version/s	10.7 [ 24805 ]
Fix Version/s	10.8 [ 26121 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Marko Mäkelä made changes - 2022-01-20 05:34

Link

This issue relates to ~~MDEV-27550~~ [ ~~MDEV-27550~~ ]

Rob Schwyzer (Inactive) made changes - 2022-02-14 19:27

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33104 ]

Rob Schwyzer (Inactive) made changes - 2022-02-14 19:32

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33105 ]

Rob Schwyzer (Inactive) made changes - 2022-02-15 22:45

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33109 ]

Marko Mäkelä made changes - 2022-02-16 15:09

Link

This issue blocks MENT-1414 [ MENT-1414 ]

Rob Schwyzer (Inactive) made changes - 2022-02-17 01:27

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33119 ]

Vladislav Lesin made changes - 2022-02-22 04:20

Fix Version/s		10.3.35 [ 27512 ]
Fix Version/s		10.4.25 [ 27510 ]

Rob Schwyzer (Inactive) made changes - 2022-02-24 00:38

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33211 ]

Marko Mäkelä made changes - 2022-02-24 09:22

Link

This issue relates to ~~MDEV-27922~~ [ ~~MDEV-27922~~ ]

Rob Schwyzer (Inactive) made changes - 2022-03-02 23:03

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33105 ]

Marko Mäkelä made changes - 2022-03-03 12:46

Link

This issue relates to ~~MDEV-27992~~ [ ~~MDEV-27992~~ ]

Marko Mäkelä added a comment - 2022-03-08 16:37

This change was reverted, because it caused the incorrect-result bug ~~MDEV-27992~~ when the PRIMARY KEY of a table was concurrently updated to a smaller value.

Marko Mäkelä added a comment - 2022-03-08 16:37 This change was reverted, because it caused the incorrect-result bug MDEV-27992 when the PRIMARY KEY of a table was concurrently updated to a smaller value.

Marko Mäkelä made changes - 2022-03-08 16:37

Link

This issue causes ~~MDEV-27992~~ [ ~~MDEV-27992~~ ]

Marko Mäkelä made changes - 2022-03-08 16:37

Link

This issue relates to ~~MDEV-27992~~ [ ~~MDEV-27992~~ ]

Vladislav Lesin made changes - 2022-03-10 08:56

Link

This issue is duplicated by MENT-1435 [ MENT-1435 ]

Rob Schwyzer (Inactive) made changes - 2022-03-10 18:05

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33262 ]

Rob Schwyzer (Inactive) made changes - 2022-03-10 18:08

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33271 ]

Rob Schwyzer (Inactive) made changes - 2022-03-16 22:42

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33303 ]

Rob Schwyzer (Inactive) made changes - 2022-03-17 20:03

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33262 ]

Rob Schwyzer (Inactive) made changes - 2022-04-14 21:51

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33649 ]

Rob Schwyzer (Inactive) made changes - 2022-04-20 20:12

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33651 ]

Rob Schwyzer (Inactive) made changes - 2022-04-20 20:23

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33656 ]

Rob Schwyzer (Inactive) made changes - 2022-04-22 21:17

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33701 ]

Rob Schwyzer (Inactive) made changes - 2022-04-27 20:09

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33725 ]

Rob Schwyzer (Inactive) made changes - 2022-05-04 21:00

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33651 ]

Rob Schwyzer (Inactive) made changes - 2022-05-23 22:26

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33829 ]

Rob Schwyzer (Inactive) made changes - 2022-08-18 19:15

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34271 ]

Vladislav Lesin added a comment - 2022-08-19 09:06

There is some interesting commit in MySQL-8: "Bug #11745929 CHANGE LOCK PRIORITY SO THAT THE TRANSACTION HOLDING S-LOCK GETS X-LOCK". It should be analyzed, it might fix the issue.

Vladislav Lesin added a comment - 2022-08-19 09:06 There is some interesting commit in MySQL-8: "Bug #11745929 CHANGE LOCK PRIORITY SO THAT THE TRANSACTION HOLDING S-LOCK GETS X-LOCK". It should be analyzed, it might fix the issue.

Rob Schwyzer (Inactive) made changes - 2022-08-26 20:43

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34411 ]

Rob Schwyzer (Inactive) made changes - 2022-09-07 22:30

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34452 ]

Rob Schwyzer (Inactive) made changes - 2022-09-08 19:09

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34454 ]

Rob Schwyzer (Inactive) made changes - 2022-09-20 21:12

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34479 ]

Rob Schwyzer (Inactive) made changes - 2022-09-21 21:58

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34482 ]

Rob Schwyzer (Inactive) made changes - 2022-09-21 22:01

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34486 ]

Rob Schwyzer (Inactive) made changes - 2022-09-28 19:29

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34505 ]

Rob Schwyzer (Inactive) made changes - 2022-10-06 16:45

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34516 ]

Rob Schwyzer (Inactive) made changes - 2022-10-13 16:50

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34530 ]

Rob Schwyzer (Inactive) made changes - 2022-10-19 20:53

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34540 ]

Vladislav Lesin added a comment - 2022-10-26 11:38 - edited

I have analysed "Bug #11745929 CHANGE LOCK PRIORITY SO THAT THE TRANSACTION HOLDING S-LOCK GETS X-LOCK" commit from Oracle.

The general reason why we reverted ~~MDEV-27025~~ is ~~MDEV-27992~~. Let's take a look ~~MDEV-27992~~ once more. Suppose we don't have ~~MDEV-27025~~ fix. And we have trx 1 which holds ordinary X-lock on some record. And trx 2 executes "DELETE FROM t" or "SELECT * FOR UPDATE" in RR. It creates waiting ordinary X-lock on the same record. And then trx 1 wants to insert some record just before the locked record. It requests insert-intention lock. And the only thing which does not let trx 1 to insert new record is that trx 2 has conflicting waiting X-lock. That is why ~~MDEV-27025~~ is not a bug, it's a feature. If trx 1 ii-lock did not conflict with waiting trx 2 ordinary X-lock, there would be phantom records in RR. And there is nothing to fix.

But, what if trx 1 holds S-lock, and tries to acquire X-lock on the same record after trx 2 created waiting X-lock? Why trx 1 should wait for trx 2? This is exactly the case of the above MySQL fix. More commonly it can be formulated as "insert-intention locks must not overtake a waiting ordinary or gap locks".

I think it could be useful for us to port that commit to fix the above issue. Besides, it contains some useful optimization:

`lock_rec_find_set_bit` which searches for the first bit set in a bitmap used bit-by-bit loop. Now it uses 13x times faster implementation which tries to skip 64,then 32,16, or 8 bits at a time. This is important for WAITING locks which have just a single bit set, in a bitmap with number of bits equal to the number of records on a page (which can be ~500).

If we port it some time, we should also port "Bug #34123159 Assertion failure: lock0lock.cc:5161:lock_rec_has_expl(LOCK_X | LOCK_REC_NOT_GAP".

One more note. In ~~MDEV-27992~~ case DELETE converts implicit lock to explicit one despite conflicting transaction already holds ordinary X-lock on the record. That is because lock_rec_convert_impl_to_expl_for_trx() checks only LOCK_X | LOCK_REC_NOT_GAP when it looks for existing explicit locks. We could include LOCK_ORDINARY in the search also.

Vladislav Lesin added a comment - 2022-10-26 11:38 - edited I have analysed "Bug #11745929 CHANGE LOCK PRIORITY SO THAT THE TRANSACTION HOLDING S-LOCK GETS X-LOCK" commit from Oracle. The general reason why we reverted MDEV-27025 is MDEV-27992 . Let's take a look MDEV-27992 once more. Suppose we don't have MDEV-27025 fix. And we have trx 1 which holds ordinary X-lock on some record. And trx 2 executes "DELETE FROM t" or "SELECT * FOR UPDATE" in RR. It creates waiting ordinary X-lock on the same record. And then trx 1 wants to insert some record just before the locked record. It requests insert-intention lock. And the only thing which does not let trx 1 to insert new record is that trx 2 has conflicting waiting X-lock. That is why MDEV-27025 is not a bug, it's a feature . If trx 1 ii-lock did not conflict with waiting trx 2 ordinary X-lock, there would be phantom records in RR. And there is nothing to fix. But, what if trx 1 holds S-lock, and tries to acquire X-lock on the same record after trx 2 created waiting X-lock? Why trx 1 should wait for trx 2? This is exactly the case of the above MySQL fix. More commonly it can be formulated as "insert-intention locks must not overtake a waiting ordinary or gap locks". I think it could be useful for us to port that commit to fix the above issue. Besides, it contains some useful optimization: `lock_rec_find_set_bit` which searches for the first bit set in a bitmap used bit-by-bit loop. Now it uses 13x times faster implementation which tries to skip 64,then 32,16, or 8 bits at a time. This is important for WAITING locks which have just a single bit set, in a bitmap with number of bits equal to the number of records on a page (which can be ~500). If we port it some time, we should also port "Bug #34123159 Assertion failure: lock0lock.cc:5161:lock_rec_has_expl(LOCK_X | LOCK_REC_NOT_GAP". One more note. In MDEV-27992 case DELETE converts implicit lock to explicit one despite conflicting transaction already holds ordinary X-lock on the record. That is because lock_rec_convert_impl_to_expl_for_trx() checks only LOCK_X | LOCK_REC_NOT_GAP when it looks for existing explicit locks. We could include LOCK_ORDINARY in the search also.

Rob Schwyzer (Inactive) made changes - 2022-10-26 23:21

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34607 ]

Rob Schwyzer (Inactive) made changes - 2022-11-03 16:40

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34613 ]

Rob Schwyzer (Inactive) made changes - 2022-11-10 17:40

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34624 ]

Rob Schwyzer (Inactive) made changes - 2022-11-17 17:54

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34643 ]

Rob Schwyzer (Inactive) made changes - 2022-11-30 22:57

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34658 ]

Rob Schwyzer (Inactive) made changes - 2022-12-08 17:34

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34678 ]

Rob Schwyzer (Inactive) made changes - 2023-01-11 22:54

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34696 ]

Rob Schwyzer (Inactive) made changes - 2023-01-19 17:52

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34716 ]

Rob Schwyzer (Inactive) made changes - 2023-01-26 17:39

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34812 ]

Rob Schwyzer (Inactive) made changes - 2023-02-02 17:58

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34828 ]

Rob Schwyzer (Inactive) made changes - 2023-02-08 23:50

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34846 ]

Rob Schwyzer (Inactive) made changes - 2023-02-16 19:00

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34916 ]

Rob Schwyzer (Inactive) made changes - 2023-02-22 18:32

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34932 ]

Rob Schwyzer (Inactive) made changes - 2023-03-02 01:08

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34948 ]

Rob Schwyzer (Inactive) made changes - 2023-03-08 23:04

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 34482 ]

Rob Schwyzer (Inactive) made changes - 2023-05-01 20:50

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33649 ]

Rob Schwyzer (Inactive) made changes - 2023-05-01 21:28

Remote Link

This issue links to "Page (MariaDB Confluence)" [ 33701 ]

Jira Automation (IT) made changes - 2024-07-04 01:58

Zendesk Related Tickets		202352 201658 136328
Zendesk active tickets		201658

Michael Widenius added a comment - 2024-08-30 10:41 - edited

What was done as part of fixing this issue ? It is not clear if anything from vlad's comment above has been addressed.

Is the issue in https://github.com/mysql/mysql-server/commit/7037a0bdc83196755a3bf3e935cfb3c0127715d5
addressed now ?
The above commit include a test case. Does that test case now work in MariaDB?

Michael Widenius added a comment - 2024-08-30 10:41 - edited What was done as part of fixing this issue ? It is not clear if anything from vlad's comment above has been addressed. Is the issue in https://github.com/mysql/mysql-server/commit/7037a0bdc83196755a3bf3e935cfb3c0127715d5 addressed now ? The above commit include a test case. Does that test case now work in MariaDB?

Michael Widenius added a comment - 2024-08-30 11:14

Note that in MariaDB 10.6 we have now optimized bit operations in my_bitmap.cc
There is no looping over bits anymore and all operations are done on 64 bits at a time.

Michael Widenius added a comment - 2024-08-30 11:14 Note that in MariaDB 10.6 we have now optimized bit operations in my_bitmap.cc There is no looping over bits anymore and all operations are done on 64 bits at a time.

Vladislav Lesin made changes - 2024-09-05 07:14

Resolution	Fixed [ 1 ]
Status	Closed [ 6 ]	Stalled [ 10000 ]

Vladislav Lesin made changes - 2024-09-05 07:15

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Vladislav Lesin made changes - 2024-09-05 10:06

Link

This issue relates to ~~MDEV-34877~~ [ ~~MDEV-34877~~ ]

Vladislav Lesin added a comment - 2024-09-05 10:09

I filed ~~MDEV-34877~~ for porting MySQL's "Bug #11745929".

Vladislav Lesin added a comment - 2024-09-05 10:09 I filed MDEV-34877 for porting MySQL's "Bug #11745929".

Vladislav Lesin made changes - 2024-09-05 10:09

Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

JiraAutomate made changes - 2024-09-05 10:09

Fix Version/s		10.5.16 [ 27508 ]
Fix Version/s		10.6.8 [ 27506 ]
Fix Version/s		10.7.4 [ 27504 ]
Fix Version/s		10.8.3 [ 27502 ]

Alessandro Vetere made changes - 2025-03-13 10:52

Remote Link

This issue links to "SAMU-292 (Jira)" [ 37454 ]

Marko Mäkelä added a comment - 2 days ago

In order to run the test ii-conflicts-waiting.test on MariaDB Server 10.6 or later, the following adjustment is needed.

@@ -18,7 +18,7 @@

 --connect(con_del,localhost,root,,)

 SET DEBUG_SYNC = 'now WAIT_FOR ins_set_locks';

-SET DEBUG_SYNC = 'lock_wait_suspend_thread_enter SIGNAL del_locked';

+SET DEBUG_SYNC = 'lock_wait_start SIGNAL del_locked';

 ###############################################################################

 # This DELETE creates waiting ORDINARY X-lock for heap_no 2 as the record is

 # delete-marked, this lock conflicts with ORDINARY S-lock set by the the last

vlad.lesin, it seems that ~~MDEV-34877~~ is not fixing the scenario of this test:

11.4 30140c066d50f7e4ac4f490a9e081d9d605aea07
mysqltest: At line 43: query 'reap' failed: ER_LOCK_DEADLOCK (1213): Deadlock found when trying to get lock; try restarting transaction

I tested this with both values of innodb_snapshot_isolation (~~MDEV-35124~~) and got the same result. Based on my reading of the analysis in ~~MDEV-27992~~, this setting should make no difference in that scenario, but I did not check that by re-applying and retesting the original fix of ~~MDEV-27025~~.

The regression ~~MDEV-27992~~, which forced us to revert the original fix, involves a scenario where some PRIMARY KEY columns are being updated, or more generally, if the same transaction is first deleting and then inserting rows in the same table. If the problems are only limited to only such scenarios, I wonder if we could treat those as a special case and enable the optimization in other cases. At the core of the ~~MDEV-27992~~ fix is the added parameter bool insert_before_waiting, which is being set in the calls of lock_rec_add_to_queue() in lock_rec_convert_impl_to_expl_for_trx() and when lock_rec_other_has_conflicting() sets was_ignored in lock_rec_lock().

Marko Mäkelä added a comment - 2 days ago In order to run the test ii-conflicts-waiting.test on MariaDB Server 10.6 or later, the following adjustment is needed. @@ -18,7 +18,7 @@ --connect(con_del,localhost,root,,) SET DEBUG_SYNC = 'now WAIT_FOR ins_set_locks'; -SET DEBUG_SYNC = 'lock_wait_suspend_thread_enter SIGNAL del_locked'; +SET DEBUG_SYNC = 'lock_wait_start SIGNAL del_locked'; ############################################################################### # This DELETE creates waiting ORDINARY X-lock for heap_no 2 as the record is # delete-marked, this lock conflicts with ORDINARY S-lock set by the the last vlad.lesin , it seems that MDEV-34877 is not fixing the scenario of this test: 11.4 30140c066d50f7e4ac4f490a9e081d9d605aea07 mysqltest: At line 43: query 'reap' failed: ER_LOCK_DEADLOCK (1213): Deadlock found when trying to get lock; try restarting transaction I tested this with both values of innodb_snapshot_isolation ( MDEV-35124 ) and got the same result. Based on my reading of the analysis in MDEV-27992 , this setting should make no difference in that scenario, but I did not check that by re-applying and retesting the original fix of MDEV-27025 . The regression MDEV-27992 , which forced us to revert the original fix, involves a scenario where some PRIMARY KEY columns are being updated, or more generally, if the same transaction is first deleting and then inserting rows in the same table. If the problems are only limited to only such scenarios, I wonder if we could treat those as a special case and enable the optimization in other cases. At the core of the MDEV-27992 fix is the added parameter bool insert_before_waiting , which is being set in the calls of lock_rec_add_to_queue() in lock_rec_convert_impl_to_expl_for_trx() and when lock_rec_other_has_conflicting() sets was_ignored in lock_rec_lock() .

MariaDB Server

insert-intention lock conflicts with waiting ORDINARY lock

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration