[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]

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 ]

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

Comment

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

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ä made changes - 2022-01-04 13:16

Assignee

Vladislav Lesin [ vlad.lesin ]

Matthias Leich [ mleich ]

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~~ ]

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

Status

Stalled [ 10000 ]

In Progress [ 3 ]

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 made changes - 2022-01-13 12:38

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

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

Status

Stalled [ 10000 ]

In Progress [ 3 ]

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ä 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ä 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 ]

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 ]

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

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 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 ]

MariaDB Server

insert-intention lock conflicts with waiting ORDINARY lock

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration