mirror of
https://github.com/MariaDB/server.git
synced 2025-01-20 05:52:27 +01:00
34de83e132
This was a deadlock between ALTER TABLE and another DML statement (or LOCK TABLES ... READ). ALTER TABLE would wait trying to upgrade its lock to MDL_EXCLUSIVE and the DML statement would wait trying to acquire a TL_READ_NO_INSERT table level lock. This could happen if one connection first acquired a MDL_SHARED_READ lock on a table. In another connection ALTER TABLE is then started. ALTER TABLE eventually blocks trying to upgrade to MDL_EXCLUSIVE, but while holding a TL_WRITE_ALLOW_READ table level lock. If the first connection then tries to acquire TL_READ_NO_INSERT, it will block and we have a deadlock since neither connection can proceed. This patch fixes the problem by allowing TL_READ_NO_INSERT locks to be granted if another connection holds TL_WRITE_ALLOW_READ on the same table. This will allow the DML statement to proceed such that it eventually can release its MDL lock which in turn makes ALTER TABLE able to proceed. Note that TL_READ_NO_INSERT was already partially compatible with TL_WRITE_ALLOW_READ as the latter would be granted if the former lock was held. This patch just makes the opposite true as well. Also note that since ALTER TABLE takes an upgradable MDL lock, there will be no starvation of ALTER TABLE statements by statements acquiring TL_READ or TL_READ_NO_INSERT. Test case added to lock_sync.test.
93 lines
3.4 KiB
Text
93 lines
3.4 KiB
Text
#
|
|
# Test for bug #45143 "All connections hang on concurrent ALTER TABLE".
|
|
#
|
|
# Concurrent execution of statements which required weak write lock
|
|
# (TL_WRITE_ALLOW_WRITE) on several instances of the same table and
|
|
# statements which tried to acquire stronger write lock (TL_WRITE,
|
|
# TL_WRITE_ALLOW_READ) on this table might have led to deadlock.
|
|
drop table if exists t1;
|
|
drop view if exists v1;
|
|
# Create auxiliary connections used through the test.
|
|
# Reset DEBUG_SYNC facility before using it.
|
|
set debug_sync= 'RESET';
|
|
# Turn off logging so calls to locking subsystem performed
|
|
# for general_log table won't interfere with our test.
|
|
set @old_general_log = @@global.general_log;
|
|
set @@global.general_log= OFF;
|
|
create table t1 (i int) engine=InnoDB;
|
|
# We have to use view in order to make LOCK TABLES avoid
|
|
# acquiring SNRW metadata lock on table.
|
|
create view v1 as select * from t1;
|
|
insert into t1 values (1);
|
|
# Prepare user lock which will be used for resuming execution of
|
|
# the first statement after it acquires TL_WRITE_ALLOW_WRITE lock.
|
|
select get_lock("lock_bug45143_wait", 0);
|
|
get_lock("lock_bug45143_wait", 0)
|
|
1
|
|
# Switch to connection 'con_bug45143_1'.
|
|
# Sending:
|
|
insert into t1 values (get_lock("lock_bug45143_wait", 100));;
|
|
# Switch to connection 'con_bug45143_2'.
|
|
# Wait until the above INSERT takes TL_WRITE_ALLOW_WRITE lock on 't1'
|
|
# and then gets blocked on user lock 'lock_bug45143_wait'.
|
|
# Ensure that upcoming SELECT waits after acquiring TL_WRITE_ALLOW_WRITE
|
|
# lock for the first instance of 't1'.
|
|
set debug_sync='thr_multi_lock_after_thr_lock SIGNAL parked WAIT_FOR go';
|
|
# Sending:
|
|
select count(*) > 0 from t1 as a, t1 as b for update;;
|
|
# Switch to connection 'con_bug45143_3'.
|
|
# Wait until the above SELECT ... FOR UPDATE is blocked after
|
|
# acquiring lock for the the first instance of 't1'.
|
|
set debug_sync= 'now WAIT_FOR parked';
|
|
# Send LOCK TABLE statement which will try to get TL_WRITE lock on 't1':
|
|
lock table v1 write;;
|
|
# Switch to connection 'default'.
|
|
# Wait until this LOCK TABLES statement starts waiting for table lock.
|
|
# Allow SELECT ... FOR UPDATE to resume.
|
|
# Since it already has TL_WRITE_ALLOW_WRITE lock on the first instance
|
|
# of 't1' it should be able to get lock on the second instance without
|
|
# waiting, even although there is another thread which has such lock
|
|
# on this table and also there is a thread waiting for a TL_WRITE on it.
|
|
set debug_sync= 'now SIGNAL go';
|
|
# Switch to connection 'con_bug45143_2'.
|
|
# Reap SELECT ... FOR UPDATE
|
|
count(*) > 0
|
|
1
|
|
# Switch to connection 'default'.
|
|
# Resume execution of the INSERT statement.
|
|
select release_lock("lock_bug45143_wait");
|
|
release_lock("lock_bug45143_wait")
|
|
1
|
|
# Switch to connection 'con_bug45143_1'.
|
|
# Reap INSERT statement.
|
|
Warnings:
|
|
Note 1592 Statement may not be safe to log in statement format.
|
|
# Switch to connection 'con_bug45143_3'.
|
|
# Reap LOCK TABLES statement.
|
|
unlock tables;
|
|
# Switch to connection 'default'.
|
|
# Do clean-up.
|
|
set debug_sync= 'RESET';
|
|
set @@global.general_log= @old_general_log;
|
|
drop view v1;
|
|
drop table t1;
|
|
#
|
|
# Bug#50821 Deadlock between LOCK TABLES and ALTER TABLE
|
|
#
|
|
DROP TABLE IF EXISTS t1, t2;
|
|
CREATE TABLE t1(id INT);
|
|
CREATE TABLE t2(id INT);
|
|
# Connection con2
|
|
START TRANSACTION;
|
|
SELECT * FROM t1;
|
|
id
|
|
# Connection default
|
|
# Sending:
|
|
ALTER TABLE t1 ADD COLUMN j INT;
|
|
# Connection con2
|
|
# This used to cause a deadlock.
|
|
INSERT INTO t2 SELECT * FROM t1;
|
|
COMMIT;
|
|
# Connection default
|
|
# Reaping ALTER TABLE t1 ADD COLUMN j INT
|
|
DROP TABLE t1, t2;
|