Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.5, 10.6, 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL), 11.3(EOL), 11.4, 11.5(EOL), 11.6(EOL), 11.7(EOL)
Description
MDEV-27025 describes the following case:
1. trx1 gets an S-lock granted
2. trx2 wants an X-lock, but has to wait for trx1
3. trx1 now wants an X-lock, but waits for trx2
The try to fix MDEV-27025 caused MDEV-27992, what made us to revert MDEV-27025 fix(see also this comment). It seems, MySQL's "Bug #11745929" fix solves MDEV-27025 issue.
Attachments
Issue Links
- is duplicated by
-
MDEV-34652 Deadlock when upgrading shared lock to exclusive
-
- Closed
-
- relates to
-
MDEV-35624 Innodb: Avoid Implicit Lock check when the lock queue is not empty
-
- Open
-
-
MDEV-35930 optimize lock_rec_find_set_bit() function
-
- Open
-
-
MDEV-35931 optimize lock_rec_has_expl() to stop iteration when waiting lock is reached
-
- Open
-
-
MDEV-35932 unify functions which are looking for conflicting record lock in locks queue
-
- Open
-
-
MDEV-18706 ER_LOCK_DEADLOCK on concurrent read and insert into already locked gap
-
- In Review
-
-
MDEV-27025 insert-intention lock conflicts with waiting ORDINARY lock
-
- Closed
-
Update:
I ported test case from MySQL and fixed all bugs found during debugging the test case. Currently, the code passed local mtr testing. I am refactoring the code to correspond to MariaDB coding standards. Then I am going to launch local RQG testing and pass it to standard RQG testing to Matthias after I catch and fix bugs locally.