mirror of
https://github.com/MariaDB/server.git
synced 2025-01-20 14:02:32 +01:00
1b5f2b9030
Bug #42147 Concurrent DML and LOCK TABLE ... READ for InnoDB table cause warnings in errlog Concurrent execution of LOCK TABLES ... READ statement and DML statements affecting the same InnoDB table on debug builds of MySQL server might lead to "Found lock of type 6 that is write and read locked" warnings appearing in error log. The problem is that the table-level locking code allows a thread to acquire TL_READ_NO_INSERT lock on a table even if there is another thread which holds TL_WRITE_ALLOW_WRITE lock on the same table. At the same time, the locking code assumes that that such locks are incompatible (for example, see check_locks()). This doesn't lead to any problems other than warnings in error log for debug builds of server since for InnoDB tables TL_READ_NO_INSERT type of lock is only used for LOCK TABLES and for this statement InnoDB also performs its own table-level locking. Unfortunately, the table lock compatibility matrix cannot be updated to disallow TL_READ_NO_INSERT when another thread holds TL_WRITE_ALLOW_WRITE without causing starvation of LOCK TABLE READ in InnoDB under high write load. This patch therefore contains no code changes. The issue will be fixed later when LOCK TABLE READ has been updated to not use table locks. This bug will therefore be marked as "To be fixed later". Code comment in thr_lock.c expanded to clarify the issue and a test case based on the bug description added to innodb_mysql_lock.test. Note that a global suppression rule has been added to both MTR v1 and v2 for the "Found lock of type 6 that is write and read locked" warning. These suppression rules must be removed once this bug is properly fixed.
56 lines
1.4 KiB
Text
56 lines
1.4 KiB
Text
#
|
|
# Bug #22876 Four-way deadlock
|
|
#
|
|
DROP TABLE IF EXISTS t1;
|
|
# Connection 1
|
|
set @@autocommit=0;
|
|
CREATE TABLE t1(s1 INT UNIQUE) ENGINE=innodb;
|
|
INSERT INTO t1 VALUES (1);
|
|
# Connection 2
|
|
set @@autocommit=0;
|
|
INSERT INTO t1 VALUES (2);
|
|
INSERT INTO t1 VALUES (1);
|
|
# Connection 3
|
|
set @@autocommit=0;
|
|
DROP TABLE t1;
|
|
# Connection 1
|
|
# Connection 1 is now holding the lock.
|
|
# Issuing insert from connection 1 while connection 2&3
|
|
# is waiting for the lock should give a deadlock error.
|
|
INSERT INTO t1 VALUES (2);
|
|
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
|
|
# Cleanup
|
|
commit;
|
|
set @@autocommit=1;
|
|
commit;
|
|
set @@autocommit=1;
|
|
set @@autocommit=1;
|
|
#
|
|
# Bug #42147 Concurrent DML and LOCK TABLE ... READ for InnoDB
|
|
# table cause warnings in errlog
|
|
#
|
|
#
|
|
# Note that this test for now relies on a global suppression of
|
|
# the warning "Found lock of type 6 that is write and read locked"
|
|
# This suppression rule can be removed once Bug#42147 is properly
|
|
# fixed. See bug page for more info.
|
|
#
|
|
DROP TABLE IF EXISTS t1;
|
|
CREATE TABLE t1 (i INT) engine= innodb;
|
|
# Connection 2
|
|
# Get user-level lock
|
|
SELECT get_lock('bug42147_lock', 60);
|
|
get_lock('bug42147_lock', 60)
|
|
1
|
|
# Connection 1
|
|
INSERT INTO t1 SELECT get_lock('bug42147_lock', 60);
|
|
# Connection 2
|
|
LOCK TABLES t1 READ;
|
|
SELECT release_lock('bug42147_lock');
|
|
release_lock('bug42147_lock')
|
|
1
|
|
# Connection 1
|
|
# Connection 2
|
|
UNLOCK TABLES;
|
|
# Connection 1
|
|
DROP TABLE t1;
|