Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
Description
Testing a fix of MDEV-15326 revealed that if the call to trx->lock.table_locks.clear(); is skipped at transaction commit when trx->lock.trx_locks is empty, occasionally a transaction would be left with nonempty trx->lock.table_locks list. This proves that the table_locks is not a subset of trx_locks, like it is expected to be.
We will need a test case for this, so that the bug can be found and fixed. To repeat the assertion failures, revert the following part of the MDEV-15326 fix:
diff --git a/storage/innobase/trx/trx0trx.cc b/storage/innobase/trx/trx0trx.cc
|
index 1dcca7c1f72..b06e15d4f37 100644
|
--- a/storage/innobase/trx/trx0trx.cc
|
+++ b/storage/innobase/trx/trx0trx.cc
|
@@ -561,8 +561,6 @@ inline void trx_t::release_locks()
|
|
if (UT_LIST_GET_LEN(lock.trx_locks))
|
lock_trx_release_locks(this);
|
- else
|
- lock.table_locks.clear(); /* Work around MDEV-20483 */
|
}
|
|
/********************************************************************//** |
This should lead to occasional assertion failures on trx->lock.table_locks.empty() on transaction commit.
Attachments
Issue Links
- relates to
-
MDEV-13426 Assertion failure ib_vector_is_empty at trx0trx.cc line 1078
- Closed
-
MDEV-15326 InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)
- Closed