2009-12-08 14:27:33 +01:00
|
|
|
-- source include/have_innodb.inc
|
|
|
|
|
2009-12-09 16:13:00 +01:00
|
|
|
# Save the initial number of concurrent sessions.
|
|
|
|
--source include/count_sessions.inc
|
|
|
|
|
2009-12-08 14:27:33 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Bug #22876 Four-way deadlock
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
connect (con1,localhost,root,,);
|
|
|
|
connect (con2,localhost,root,,);
|
|
|
|
connect (con3,localhost,root,,);
|
|
|
|
|
|
|
|
--echo # Connection 1
|
|
|
|
connection con1;
|
|
|
|
set @@autocommit=0;
|
|
|
|
CREATE TABLE t1(s1 INT UNIQUE) ENGINE=innodb;
|
|
|
|
INSERT INTO t1 VALUES (1);
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connection con2;
|
|
|
|
set @@autocommit=0;
|
|
|
|
INSERT INTO t1 VALUES (2);
|
|
|
|
--send INSERT INTO t1 VALUES (1)
|
|
|
|
|
|
|
|
--echo # Connection 3
|
|
|
|
connection con3;
|
|
|
|
set @@autocommit=0;
|
|
|
|
--send DROP TABLE t1
|
|
|
|
|
|
|
|
--echo # Connection 1
|
|
|
|
connection con1;
|
|
|
|
let $wait_condition=
|
|
|
|
SELECT COUNT(*) = 1 FROM information_schema.processlist
|
|
|
|
WHERE info = "INSERT INTO t1 VALUES (1)" and
|
|
|
|
state = "update";
|
|
|
|
--source include/wait_condition.inc
|
|
|
|
let $wait_condition=
|
|
|
|
SELECT COUNT(*) = 1 FROM information_schema.processlist
|
|
|
|
WHERE info = "DROP TABLE t1" and
|
2010-08-06 15:29:37 +04:00
|
|
|
state = "Waiting for table metadata lock";
|
2009-12-08 14:27:33 +01:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
--echo # Connection 1 is now holding the lock.
|
|
|
|
--echo # Issuing insert from connection 1 while connection 2&3
|
|
|
|
--echo # is waiting for the lock should give a deadlock error.
|
|
|
|
--error ER_LOCK_DEADLOCK
|
|
|
|
INSERT INTO t1 VALUES (2);
|
|
|
|
|
|
|
|
--echo # Cleanup
|
|
|
|
connection con2;
|
|
|
|
--reap
|
|
|
|
commit;
|
2009-12-09 16:13:00 +01:00
|
|
|
set @@autocommit=1;
|
2009-12-08 14:27:33 +01:00
|
|
|
connection con1;
|
|
|
|
commit;
|
2009-12-09 16:13:00 +01:00
|
|
|
set @@autocommit=1;
|
2009-12-08 14:27:33 +01:00
|
|
|
connection con3;
|
|
|
|
--reap
|
2009-12-09 16:13:00 +01:00
|
|
|
set @@autocommit=1;
|
2009-12-08 14:27:33 +01:00
|
|
|
connection default;
|
2009-12-09 16:13:00 +01:00
|
|
|
|
|
|
|
disconnect con1;
|
|
|
|
disconnect con3;
|
|
|
|
|
Implement new type-of-operation-aware metadata locks.
Add a wait-for graph based deadlock detector to the
MDL subsystem.
Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
bug #37346 "innodb does not detect deadlock between update and
alter table".
The first bug manifested itself as an unwarranted abort of a
transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
statement, when this transaction tried to repeat use of a
table, which it has already used in a similar fashion before
ALTER started.
The second bug showed up as a deadlock between table-level
locks and InnoDB row locks, which was "detected" only after
innodb_lock_wait_timeout timeout.
A transaction would start using the table and modify a few
rows.
Then ALTER TABLE would come in, and start copying rows
into a temporary table. Eventually it would stumble on
the modified records and get blocked on a row lock.
The first transaction would try to do more updates, and get
blocked on thr_lock.c lock.
This situation of circular wait would only get resolved
by a timeout.
Both these bugs stemmed from inadequate solutions to the
problem of deadlocks occurring between different
locking subsystems.
In the first case we tried to avoid deadlocks between metadata
locking and table-level locking subsystems, when upgrading shared
metadata lock to exclusive one.
Transactions holding the shared lock on the table and waiting for
some table-level lock used to be aborted too aggressively.
We also allowed ALTER TABLE to start in presence of transactions
that modify the subject table. ALTER TABLE acquires
TL_WRITE_ALLOW_READ lock at start, and that block all writes
against the table (naturally, we don't want any writes to be lost
when switching the old and the new table). TL_WRITE_ALLOW_READ
lock, in turn, would block the started transaction on thr_lock.c
lock, should they do more updates. This, again, lead to the need
to abort such transactions.
The second bug occurred simply because we didn't have any
mechanism to detect deadlocks between the table-level locks
in thr_lock.c and row-level locks in InnoDB, other than
innodb_lock_wait_timeout.
This patch solves both these problems by moving lock conflicts
which are causing these deadlocks into the metadata locking
subsystem, thus making it possible to avoid or detect such
deadlocks inside MDL.
To do this we introduce new type-of-operation-aware metadata
locks, which allow MDL subsystem to know not only the fact that
transaction has used or is going to use some object but also what
kind of operation it has carried out or going to carry out on the
object.
This, along with the addition of a special kind of upgradable
metadata lock, allows ALTER TABLE to wait until all
transactions which has updated the table to go away.
This solves the second issue.
Another special type of upgradable metadata lock is acquired
by LOCK TABLE WRITE. This second lock type allows to solve the
first issue, since abortion of table-level locks in event of
DDL under LOCK TABLES becomes also unnecessary.
Below follows the list of incompatible changes introduced by
this patch:
- From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
statements that acquire TL_WRITE_ALLOW_READ lock)
wait for all transactions which has *updated* the table to
complete.
- From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
(i.e. all statements which acquire TL_WRITE table-level lock) wait
for all transaction which *updated or read* from the table
to complete.
As a consequence, innodb_table_locks=0 option no longer applies
to LOCK TABLES ... WRITE.
- DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
statements or transactions which use tables being dropped or
renamed, and instead wait for these transactions to complete.
- Since LOCK TABLES WRITE now takes a special metadata lock,
not compatible with with reads or writes against the subject table
and transaction-wide, thr_lock.c deadlock avoidance algorithm
that used to ensure absence of deadlocks between LOCK TABLES
WRITE and other statements is no longer sufficient, even for
MyISAM. The wait-for graph based deadlock detector of MDL
subsystem may sometimes be necessary and is involved. This may
lead to ER_LOCK_DEADLOCK error produced for multi-statement
transactions even if these only use MyISAM:
session 1: session 2:
begin;
update t1 ... lock table t2 write, t1 write;
-- gets a lock on t2, blocks on t1
update t2 ...
(ER_LOCK_DEADLOCK)
- Finally, support of LOW_PRIORITY option for LOCK TABLES ... WRITE
was abandoned.
LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
priority as the usual LOCK TABLE ... WRITE.
SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE in
the wait queue.
- We do not take upgradable metadata locks on implicitly
locked tables. So if one has, say, a view v1 that uses
table t1, and issues:
LOCK TABLE v1 WRITE;
FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
an error is produced.
In order to be able to perform DDL on a table under LOCK TABLES,
the table must be locked explicitly in the LOCK TABLES list.
2010-02-01 14:43:06 +03:00
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test for bug #37346 "innodb does not detect deadlock between update
|
|
|
|
--echo # and alter table".
|
|
|
|
--echo #
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
--enable_warnings
|
|
|
|
create table t1 (c1 int primary key, c2 int, c3 int) engine=InnoDB;
|
|
|
|
insert into t1 values (1,1,0),(2,2,0),(3,3,0),(4,4,0),(5,5,0);
|
|
|
|
begin;
|
|
|
|
--echo # Run statement which acquires X-lock on one of table's rows.
|
|
|
|
update t1 set c3=c3+1 where c2=3;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Switching to connection 'con37346'.
|
|
|
|
connect (con37346,localhost,root,,test,,);
|
|
|
|
connection con37346;
|
|
|
|
--echo # The below ALTER TABLE statement should wait till transaction
|
|
|
|
--echo # in connection 'default' is complete and then succeed.
|
|
|
|
--echo # It should not deadlock or fail with ER_LOCK_DEADLOCK error.
|
|
|
|
--echo # Sending:
|
|
|
|
--send alter table t1 add column c4 int;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Switching to connection 'default'.
|
|
|
|
connection default;
|
|
|
|
--echo # Wait until the above ALTER TABLE gets blocked because this
|
|
|
|
--echo # connection holds SW metadata lock on table to be altered.
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table metadata lock" and
|
|
|
|
info = "alter table t1 add column c4 int";
|
Implement new type-of-operation-aware metadata locks.
Add a wait-for graph based deadlock detector to the
MDL subsystem.
Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
bug #37346 "innodb does not detect deadlock between update and
alter table".
The first bug manifested itself as an unwarranted abort of a
transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
statement, when this transaction tried to repeat use of a
table, which it has already used in a similar fashion before
ALTER started.
The second bug showed up as a deadlock between table-level
locks and InnoDB row locks, which was "detected" only after
innodb_lock_wait_timeout timeout.
A transaction would start using the table and modify a few
rows.
Then ALTER TABLE would come in, and start copying rows
into a temporary table. Eventually it would stumble on
the modified records and get blocked on a row lock.
The first transaction would try to do more updates, and get
blocked on thr_lock.c lock.
This situation of circular wait would only get resolved
by a timeout.
Both these bugs stemmed from inadequate solutions to the
problem of deadlocks occurring between different
locking subsystems.
In the first case we tried to avoid deadlocks between metadata
locking and table-level locking subsystems, when upgrading shared
metadata lock to exclusive one.
Transactions holding the shared lock on the table and waiting for
some table-level lock used to be aborted too aggressively.
We also allowed ALTER TABLE to start in presence of transactions
that modify the subject table. ALTER TABLE acquires
TL_WRITE_ALLOW_READ lock at start, and that block all writes
against the table (naturally, we don't want any writes to be lost
when switching the old and the new table). TL_WRITE_ALLOW_READ
lock, in turn, would block the started transaction on thr_lock.c
lock, should they do more updates. This, again, lead to the need
to abort such transactions.
The second bug occurred simply because we didn't have any
mechanism to detect deadlocks between the table-level locks
in thr_lock.c and row-level locks in InnoDB, other than
innodb_lock_wait_timeout.
This patch solves both these problems by moving lock conflicts
which are causing these deadlocks into the metadata locking
subsystem, thus making it possible to avoid or detect such
deadlocks inside MDL.
To do this we introduce new type-of-operation-aware metadata
locks, which allow MDL subsystem to know not only the fact that
transaction has used or is going to use some object but also what
kind of operation it has carried out or going to carry out on the
object.
This, along with the addition of a special kind of upgradable
metadata lock, allows ALTER TABLE to wait until all
transactions which has updated the table to go away.
This solves the second issue.
Another special type of upgradable metadata lock is acquired
by LOCK TABLE WRITE. This second lock type allows to solve the
first issue, since abortion of table-level locks in event of
DDL under LOCK TABLES becomes also unnecessary.
Below follows the list of incompatible changes introduced by
this patch:
- From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
statements that acquire TL_WRITE_ALLOW_READ lock)
wait for all transactions which has *updated* the table to
complete.
- From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
(i.e. all statements which acquire TL_WRITE table-level lock) wait
for all transaction which *updated or read* from the table
to complete.
As a consequence, innodb_table_locks=0 option no longer applies
to LOCK TABLES ... WRITE.
- DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
statements or transactions which use tables being dropped or
renamed, and instead wait for these transactions to complete.
- Since LOCK TABLES WRITE now takes a special metadata lock,
not compatible with with reads or writes against the subject table
and transaction-wide, thr_lock.c deadlock avoidance algorithm
that used to ensure absence of deadlocks between LOCK TABLES
WRITE and other statements is no longer sufficient, even for
MyISAM. The wait-for graph based deadlock detector of MDL
subsystem may sometimes be necessary and is involved. This may
lead to ER_LOCK_DEADLOCK error produced for multi-statement
transactions even if these only use MyISAM:
session 1: session 2:
begin;
update t1 ... lock table t2 write, t1 write;
-- gets a lock on t2, blocks on t1
update t2 ...
(ER_LOCK_DEADLOCK)
- Finally, support of LOW_PRIORITY option for LOCK TABLES ... WRITE
was abandoned.
LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
priority as the usual LOCK TABLE ... WRITE.
SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE in
the wait queue.
- We do not take upgradable metadata locks on implicitly
locked tables. So if one has, say, a view v1 that uses
table t1, and issues:
LOCK TABLE v1 WRITE;
FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
an error is produced.
In order to be able to perform DDL on a table under LOCK TABLES,
the table must be locked explicitly in the LOCK TABLES list.
2010-02-01 14:43:06 +03:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
|
|
|
|
--echo # The below statement should succeed. It should not
|
|
|
|
--echo # deadlock or end with ER_LOCK_DEADLOCK error.
|
|
|
|
update t1 set c3=c3+1 where c2=4;
|
|
|
|
|
|
|
|
--echo # Unblock ALTER TABLE by committing transaction.
|
|
|
|
commit;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Switching to connection 'con37346'.
|
|
|
|
connection con37346;
|
|
|
|
--echo # Reaping ALTER TABLE.
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Switching to connection 'default'.
|
|
|
|
connection default;
|
|
|
|
disconnect con37346;
|
|
|
|
drop table t1;
|
|
|
|
|
|
|
|
|
2009-12-09 16:13:00 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Bug #42147 Concurrent DML and LOCK TABLE ... READ for InnoDB
|
|
|
|
--echo # table cause warnings in errlog
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Note that this test for now relies on a global suppression of
|
|
|
|
--echo # the warning "Found lock of type 6 that is write and read locked"
|
|
|
|
--echo # This suppression rule can be removed once Bug#42147 is properly
|
|
|
|
--echo # fixed. See bug page for more info.
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
CREATE TABLE t1 (i INT) engine= innodb;
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
--echo # Get user-level lock
|
|
|
|
connection con2;
|
|
|
|
SELECT get_lock('bug42147_lock', 60);
|
|
|
|
|
|
|
|
--echo # Connection 1
|
|
|
|
connection default;
|
|
|
|
--send INSERT INTO t1 SELECT get_lock('bug42147_lock', 60)
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connection con2;
|
|
|
|
let $wait_condition=
|
|
|
|
SELECT COUNT(*) > 0 FROM information_schema.processlist
|
|
|
|
WHERE state = 'User lock'
|
|
|
|
AND info = 'INSERT INTO t1 SELECT get_lock(\'bug42147_lock\', 60)';
|
|
|
|
--source include/wait_condition.inc
|
|
|
|
LOCK TABLES t1 READ;
|
|
|
|
SELECT release_lock('bug42147_lock');
|
|
|
|
|
|
|
|
--echo # Connection 1
|
|
|
|
connection default;
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connection con2;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
|
|
|
--echo # Connection 1
|
|
|
|
connection default;
|
|
|
|
disconnect con2;
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
2010-05-19 13:32:21 +02:00
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Bug#53798 OPTIMIZE TABLE breaks repeatable read
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
CREATE TABLE t1 (a INT) engine=innodb;
|
|
|
|
INSERT INTO t1 VALUES (1), (2), (3);
|
|
|
|
|
|
|
|
--echo # Connection con1
|
|
|
|
connect (con1, localhost, root);
|
|
|
|
START TRANSACTION WITH CONSISTENT SNAPSHOT;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
--echo # This should block
|
|
|
|
--echo # Sending:
|
|
|
|
--send OPTIMIZE TABLE t1
|
|
|
|
|
|
|
|
--echo # Connection con1
|
|
|
|
connection con1;
|
|
|
|
let $wait_condition=SELECT COUNT(*)=1 FROM information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
WHERE state='Waiting for table metadata lock' AND info='OPTIMIZE TABLE t1';
|
2010-05-19 13:32:21 +02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
SELECT * FROM t1;
|
|
|
|
COMMIT;
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
--echo # Reaping OPTIMIZE TABLE t1
|
|
|
|
--reap
|
|
|
|
disconnect con1;
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
|
|
|
|
2010-06-26 22:23:28 +02:00
|
|
|
--echo #
|
|
|
|
--echo # Bug#49891 View DDL breaks REPEATABLE READ
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1, t2;
|
|
|
|
DROP VIEW IF EXISTS v2;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
CREATE TABLE t1 ( f1 INTEGER ) ENGINE = innodb;
|
|
|
|
CREATE TABLE t2 ( f1 INTEGER );
|
|
|
|
CREATE VIEW v1 AS SELECT 1 FROM t1;
|
|
|
|
|
|
|
|
connect (con2, localhost, root);
|
|
|
|
connect (con3, localhost, root);
|
|
|
|
|
|
|
|
--echo # Connection con3
|
|
|
|
connection con3;
|
|
|
|
LOCK TABLE t1 WRITE;
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
START TRANSACTION;
|
|
|
|
# This should block due to t1 being locked.
|
|
|
|
--echo # Sending:
|
|
|
|
--send SELECT * FROM v1
|
|
|
|
|
|
|
|
--echo # Connection con2
|
|
|
|
connection con2;
|
|
|
|
--echo # Waiting for 'SELECT * FROM v1' to sync in.
|
|
|
|
let $wait_condition=
|
|
|
|
SELECT COUNT(*) = 1 FROM information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
WHERE state = "Waiting for table metadata lock" AND info = "SELECT * FROM v1";
|
2010-06-26 22:23:28 +02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
# This should block due to v1 being locked.
|
|
|
|
--echo # Sending:
|
|
|
|
--send ALTER VIEW v1 AS SELECT 2 FROM t2
|
|
|
|
|
|
|
|
--echo # Connection con3
|
|
|
|
connection con3;
|
|
|
|
--echo # Waiting for 'ALTER VIEW v1 AS SELECT 2 FROM t2' to sync in.
|
|
|
|
let $wait_condition=
|
|
|
|
SELECT COUNT(*) = 1 FROM information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
WHERE state = "Waiting for table metadata lock" AND
|
|
|
|
info = "ALTER VIEW v1 AS SELECT 2 FROM t2";
|
2010-06-26 22:23:28 +02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
# Unlock t1 allowing SELECT * FROM v1 to proceed.
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
|
|
|
--echo # Connection default;
|
|
|
|
connection default;
|
|
|
|
--echo # Reaping: SELECT * FROM v1
|
|
|
|
--reap
|
|
|
|
SELECT * FROM v1;
|
|
|
|
COMMIT;
|
|
|
|
|
|
|
|
--echo # Connection con2
|
|
|
|
connection con2;
|
|
|
|
--echo # Reaping: ALTER VIEW v1 AS SELECT 2 FROM t2
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
DROP TABLE t1, t2;
|
|
|
|
DROP VIEW v1;
|
|
|
|
disconnect con2;
|
|
|
|
disconnect con3;
|
|
|
|
|
|
|
|
|
2009-12-09 16:13:00 +01:00
|
|
|
# Check that all connections opened by test cases in this file are really
|
|
|
|
# gone so execution of other tests won't be affected by their presence.
|
|
|
|
--source include/wait_until_count_sessions.inc
|