2009-03-03 21:34:18 +01:00
|
|
|
# Save the initial number of concurrent sessions
|
|
|
|
--source include/count_sessions.inc
|
|
|
|
|
2003-01-06 01:48:59 +02:00
|
|
|
--disable_warnings
|
2003-03-04 12:22:35 +02:00
|
|
|
drop table if exists t1,t2;
|
2003-01-06 01:48:59 +02:00
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
# Test to see if select will get the lock ahead of low priority update
|
2001-10-08 04:58:07 +03:00
|
|
|
|
|
|
|
connect (locker,localhost,root,,);
|
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
|
|
|
connect (locker2,localhost,root,,);
|
2001-10-08 04:58:07 +03:00
|
|
|
connect (reader,localhost,root,,);
|
|
|
|
connect (writer,localhost,root,,);
|
|
|
|
|
|
|
|
connection locker;
|
|
|
|
create table t1(n int);
|
|
|
|
insert into t1 values (1);
|
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
|
|
|
connection locker2;
|
|
|
|
select get_lock("mysqltest_lock", 100);
|
|
|
|
connection locker;
|
|
|
|
send
|
|
|
|
update t1 set n = 2 and get_lock('mysqltest_lock', 100);
|
2001-10-08 04:58:07 +03:00
|
|
|
connection writer;
|
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
|
|
|
# Wait till above update gets blocked on a user lock.
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
|
|
|
where state = "User lock" and info = "update t1 set n = 2 and get_lock('mysqltest_lock', 100)";
|
|
|
|
--source include/wait_condition.inc
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
|
|
|
update low_priority t1 set n = 4;
|
2001-10-08 04:58:07 +03:00
|
|
|
connection reader;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Sleep a bit till the update of connection writer is in work and hangs
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table level lock" and
|
|
|
|
info = "update low_priority t1 set n = 4";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
|
|
|
select n from t1;
|
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
|
|
|
connection locker2;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Sleep a bit till the select of connection reader is in work and hangs
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table level lock" and
|
|
|
|
info = "select n from t1";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
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
|
|
|
select release_lock("mysqltest_lock");
|
|
|
|
connection locker;
|
|
|
|
reap;
|
|
|
|
select release_lock("mysqltest_lock");
|
2001-10-08 04:58:07 +03:00
|
|
|
connection writer;
|
|
|
|
reap;
|
|
|
|
connection reader;
|
|
|
|
reap;
|
|
|
|
drop table t1;
|
|
|
|
|
|
|
|
connection locker;
|
|
|
|
create table t1(n int);
|
|
|
|
insert into t1 values (1);
|
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
|
|
|
connection locker2;
|
|
|
|
select get_lock("mysqltest_lock", 100);
|
|
|
|
connection locker;
|
|
|
|
send
|
|
|
|
select n from t1 where get_lock('mysqltest_lock', 100);
|
2001-10-08 04:58:07 +03:00
|
|
|
connection writer;
|
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
|
|
|
# Wait till above select gets blocked on a user lock.
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
|
|
|
where state = "User lock" and info = "select n from t1 where get_lock('mysqltest_lock', 100)";
|
|
|
|
--source include/wait_condition.inc
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
|
|
|
update low_priority t1 set n = 4;
|
2001-10-08 04:58:07 +03:00
|
|
|
connection reader;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Sleep a bit till the update of connection writer is in work and hangs
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table level lock" and
|
|
|
|
info = "update low_priority t1 set n = 4";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
select n from t1;
|
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
|
|
|
connection locker2;
|
|
|
|
select release_lock("mysqltest_lock");
|
2001-10-08 04:58:07 +03:00
|
|
|
connection locker;
|
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
|
|
|
reap;
|
|
|
|
select release_lock("mysqltest_lock");
|
2001-10-08 04:58:07 +03:00
|
|
|
connection writer;
|
|
|
|
reap;
|
|
|
|
drop table t1;
|
2003-03-04 12:22:35 +02:00
|
|
|
|
2004-10-03 00:20:47 +01:00
|
|
|
#
|
|
|
|
# Test problem when using locks with multi-updates
|
|
|
|
# It should not block when multi-update is reading on a read-locked table
|
|
|
|
#
|
|
|
|
|
|
|
|
connection locker;
|
|
|
|
create table t1 (a int, b int);
|
|
|
|
create table t2 (c int, d int);
|
|
|
|
insert into t1 values(1,1);
|
|
|
|
insert into t1 values(2,2);
|
|
|
|
insert into t2 values(1,2);
|
|
|
|
lock table t1 read;
|
|
|
|
connection writer;
|
2007-08-11 14:07:49 +04:00
|
|
|
update t1,t2 set c=a where b=d;
|
2004-10-03 00:20:47 +01:00
|
|
|
connection reader;
|
|
|
|
select c from t2;
|
|
|
|
connection locker;
|
2009-11-20 22:51:12 +03:00
|
|
|
unlock tables;
|
2004-10-03 00:20:47 +01:00
|
|
|
drop table t1;
|
|
|
|
drop table t2;
|
|
|
|
|
2003-03-04 12:22:35 +02:00
|
|
|
#
|
2009-03-03 21:34:18 +01:00
|
|
|
# Test problem when using locks on many tables and dropping a table that
|
2003-03-04 12:22:35 +02:00
|
|
|
# is to-be-locked by another thread
|
|
|
|
#
|
2007-08-11 14:07:49 +04:00
|
|
|
#
|
2003-03-04 12:22:35 +02:00
|
|
|
connection locker;
|
|
|
|
create table t1 (a int);
|
|
|
|
create table t2 (a int);
|
|
|
|
lock table t1 write, t2 write;
|
|
|
|
connection reader;
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
|
|
|
insert t1 select * from t2;
|
2003-03-04 12:22:35 +02:00
|
|
|
connection locker;
|
2007-08-11 14:07:49 +04:00
|
|
|
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 = "insert t1 select * from t2";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
2003-03-04 12:22:35 +02:00
|
|
|
drop table t2;
|
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
|
|
|
unlock tables;
|
2003-03-04 12:22:35 +02:00
|
|
|
connection reader;
|
2009-03-06 15:56:17 +01:00
|
|
|
--error ER_NO_SUCH_TABLE
|
2003-03-04 12:22:35 +02:00
|
|
|
reap;
|
|
|
|
connection locker;
|
|
|
|
drop table t1;
|
2005-06-03 15:29:05 +02:00
|
|
|
|
2006-03-29 14:27:36 +03:00
|
|
|
#
|
|
|
|
# Same test as above, but with the dropped table locked twice
|
|
|
|
#
|
|
|
|
|
|
|
|
connection locker;
|
|
|
|
create table t1 (a int);
|
|
|
|
create table t2 (a int);
|
|
|
|
lock table t1 write, t2 write, t1 as t1_2 write, t2 as t2_2 write;
|
|
|
|
connection reader;
|
2009-03-06 15:56:17 +01:00
|
|
|
send
|
|
|
|
insert t1 select * from t2;
|
2006-03-29 14:27:36 +03:00
|
|
|
connection locker;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Sleep a bit till the insert of connection reader is in work and hangs
|
2007-08-11 14:07:49 +04:00
|
|
|
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 = "insert t1 select * from t2";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
2006-03-29 14:27:36 +03:00
|
|
|
drop table t2;
|
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
|
|
|
unlock tables;
|
2006-03-29 14:27:36 +03:00
|
|
|
connection reader;
|
2009-03-03 21:34:18 +01:00
|
|
|
--error ER_NO_SUCH_TABLE
|
2006-03-29 14:27:36 +03:00
|
|
|
reap;
|
|
|
|
connection locker;
|
|
|
|
drop table t1;
|
|
|
|
|
|
|
|
|
2007-08-11 14:07:49 +04:00
|
|
|
--echo End of 4.1 tests
|
2005-06-03 15:29:05 +02:00
|
|
|
|
|
|
|
#
|
2009-03-03 21:34:18 +01:00
|
|
|
# Bug#9998 MySQL client hangs on USE "database"
|
2005-07-28 17:09:54 +03:00
|
|
|
#
|
2005-06-03 15:29:05 +02:00
|
|
|
create table t1(a int);
|
|
|
|
lock tables t1 write;
|
|
|
|
connection reader;
|
|
|
|
show columns from t1;
|
|
|
|
connection locker;
|
|
|
|
unlock tables;
|
|
|
|
drop table t1;
|
2006-05-24 17:21:35 +03:00
|
|
|
|
2006-06-23 17:27:54 -04:00
|
|
|
#
|
2009-03-03 21:34:18 +01:00
|
|
|
# Bug#16986 Deadlock condition with MyISAM tables
|
2006-05-24 17:21:35 +03:00
|
|
|
#
|
2007-02-27 11:39:29 +01:00
|
|
|
|
|
|
|
# Need a matching user in mysql.user for multi-table select
|
|
|
|
--source include/add_anonymous_users.inc
|
|
|
|
|
2006-05-24 17:21:35 +03:00
|
|
|
connection locker;
|
2009-03-03 21:34:18 +01:00
|
|
|
USE mysql;
|
2006-05-24 17:21:35 +03:00
|
|
|
LOCK TABLES columns_priv WRITE, db WRITE, host WRITE, user WRITE;
|
|
|
|
FLUSH TABLES;
|
|
|
|
#
|
|
|
|
connection reader;
|
2009-03-03 21:34:18 +01:00
|
|
|
USE mysql;
|
|
|
|
# Note: This must be a multi-table select, otherwise the deadlock will not occur
|
|
|
|
send
|
|
|
|
SELECT user.Select_priv FROM user, db WHERE user.user = db.user LIMIT 1;
|
2006-05-24 17:21:35 +03:00
|
|
|
#
|
|
|
|
connection locker;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Sleep a bit till the select of connection reader is in work and hangs
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
2009-12-03 23:08:27 +03:00
|
|
|
SELECT COUNT(*) = 1 FROM information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
WHERE state = "Waiting for table metadata lock" AND info =
|
2007-08-11 14:07:49 +04:00
|
|
|
"SELECT user.Select_priv FROM user, db WHERE user.user = db.user LIMIT 1";
|
|
|
|
--source include/wait_condition.inc
|
2006-05-24 17:21:35 +03:00
|
|
|
# Make test case independent from earlier grants.
|
|
|
|
--replace_result "Table is already up to date" "OK"
|
|
|
|
OPTIMIZE TABLES columns_priv, db, host, user;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
#
|
|
|
|
connection reader;
|
|
|
|
reap;
|
2009-03-03 21:34:18 +01:00
|
|
|
USE test;
|
2006-05-24 17:21:35 +03:00
|
|
|
#
|
|
|
|
connection locker;
|
|
|
|
use test;
|
|
|
|
#
|
|
|
|
connection default;
|
2006-06-26 19:14:35 +02:00
|
|
|
#
|
|
|
|
# Test if CREATE TABLE with LOCK TABLE deadlocks.
|
|
|
|
#
|
|
|
|
connection writer;
|
|
|
|
CREATE TABLE t1 (c1 int);
|
|
|
|
LOCK TABLE t1 WRITE;
|
|
|
|
#
|
|
|
|
# This waits until t1 is unlocked.
|
|
|
|
connection locker;
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
|
|
|
FLUSH TABLES WITH READ LOCK;
|
2006-06-26 19:14:35 +02:00
|
|
|
#
|
|
|
|
connection writer;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Sleep a bit till the flush of connection locker is in work and hangs
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock" and
|
|
|
|
info = "FLUSH TABLES WITH READ LOCK";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
# This must not block.
|
2009-12-10 11:53:20 +01:00
|
|
|
--error ER_TABLE_NOT_LOCKED
|
2006-06-26 19:14:35 +02:00
|
|
|
CREATE TABLE t2 (c1 int);
|
|
|
|
UNLOCK TABLES;
|
|
|
|
#
|
|
|
|
# This awakes now.
|
|
|
|
connection locker;
|
|
|
|
reap;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
#
|
|
|
|
connection default;
|
2009-12-10 11:53:20 +01:00
|
|
|
DROP TABLE t1;
|
2006-06-26 19:14:35 +02:00
|
|
|
#
|
|
|
|
# Test if CREATE TABLE SELECT with LOCK TABLE deadlocks.
|
|
|
|
#
|
|
|
|
connection writer;
|
|
|
|
CREATE TABLE t1 (c1 int);
|
|
|
|
LOCK TABLE t1 WRITE;
|
|
|
|
#
|
|
|
|
# This waits until t1 is unlocked.
|
|
|
|
connection locker;
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
|
|
|
FLUSH TABLES WITH READ LOCK;
|
2006-06-26 19:14:35 +02:00
|
|
|
#
|
|
|
|
# This must not block.
|
|
|
|
connection writer;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Sleep a bit till the flush of connection locker is in work and hangs
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock" and
|
|
|
|
info = "FLUSH TABLES WITH READ LOCK";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
2009-03-03 21:34:18 +01:00
|
|
|
--error ER_TABLE_NOT_LOCKED
|
2006-06-26 19:14:35 +02:00
|
|
|
CREATE TABLE t2 AS SELECT * FROM t1;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
#
|
|
|
|
# This awakes now.
|
|
|
|
connection locker;
|
|
|
|
reap;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
#
|
|
|
|
connection default;
|
|
|
|
DROP TABLE t1;
|
2006-05-24 17:21:35 +03:00
|
|
|
|
2007-02-27 11:39:29 +01:00
|
|
|
--source include/delete_anonymous_users.inc
|
|
|
|
|
2006-07-04 12:34:23 +02:00
|
|
|
#
|
2009-03-06 15:56:17 +01:00
|
|
|
# Bug#19815 CREATE/RENAME/DROP DATABASE can deadlock on a global read lock
|
2006-07-04 12:34:23 +02:00
|
|
|
#
|
|
|
|
connect (con1,localhost,root,,);
|
|
|
|
connect (con2,localhost,root,,);
|
|
|
|
#
|
|
|
|
connection con1;
|
|
|
|
CREATE DATABASE mysqltest_1;
|
|
|
|
FLUSH TABLES WITH READ LOCK;
|
|
|
|
#
|
|
|
|
# With bug in place: acquire LOCK_mysql_create_table and
|
|
|
|
# wait in wait_if_global_read_lock().
|
|
|
|
connection con2;
|
2009-03-06 15:56:17 +01:00
|
|
|
send
|
|
|
|
DROP DATABASE mysqltest_1;
|
2006-07-04 12:34:23 +02:00
|
|
|
#
|
|
|
|
# With bug in place: try to acquire LOCK_mysql_create_table...
|
|
|
|
# When fixed: Reject dropping db because of the read lock.
|
|
|
|
connection con1;
|
2009-03-23 17:08:48 +01:00
|
|
|
# Wait a bit so that the session con2 is in state "Waiting for release of readlock"
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
|
|
|
where state = "Waiting for release of readlock"
|
|
|
|
and info = "DROP DATABASE mysqltest_1";
|
|
|
|
--source include/wait_condition.inc
|
2006-07-04 12:34:23 +02:00
|
|
|
--error ER_CANT_UPDATE_WITH_READLOCK
|
|
|
|
DROP DATABASE mysqltest_1;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
#
|
|
|
|
connection con2;
|
|
|
|
reap;
|
|
|
|
#
|
|
|
|
connection default;
|
|
|
|
disconnect con1;
|
|
|
|
disconnect con2;
|
|
|
|
# This must have been dropped by connection 2 already,
|
|
|
|
# which waited until the global read lock was released.
|
|
|
|
--error ER_DB_DROP_EXISTS
|
|
|
|
DROP DATABASE mysqltest_1;
|
|
|
|
|
2006-06-20 13:43:13 -04:00
|
|
|
#
|
2009-03-03 21:34:18 +01:00
|
|
|
# Bug#17264 MySQL Server freeze
|
2006-06-20 13:43:13 -04:00
|
|
|
#
|
|
|
|
connection locker;
|
2006-09-28 15:13:40 +02:00
|
|
|
# Disable warnings to allow test to run also without InnoDB
|
|
|
|
--disable_warnings
|
2006-06-20 13:43:13 -04:00
|
|
|
create table t1 (f1 int(12) unsigned not null auto_increment, primary key(f1)) engine=innodb;
|
2006-09-28 15:13:40 +02:00
|
|
|
--enable_warnings
|
2006-06-20 13:43:13 -04:00
|
|
|
lock tables t1 write;
|
|
|
|
connection writer;
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
2009-03-06 15:56:17 +01:00
|
|
|
alter table t1 auto_increment=0;
|
2006-06-20 13:43:13 -04:00
|
|
|
connection reader;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Wait till connection writer is blocked
|
2007-08-11 14:07:49 +04:00
|
|
|
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 auto_increment=0";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
2009-03-03 21:34:18 +01:00
|
|
|
send
|
2009-03-06 15:56:17 +01:00
|
|
|
alter table t1 auto_increment=0;
|
2006-06-20 13:43:13 -04:00
|
|
|
connection locker;
|
2009-03-03 21:34:18 +01:00
|
|
|
# Wait till connection reader is blocked
|
2007-08-11 14:07:49 +04:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 2 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table metadata lock" and
|
|
|
|
info = "alter table t1 auto_increment=0";
|
2007-08-11 14:07:49 +04:00
|
|
|
--source include/wait_condition.inc
|
2006-06-20 13:43:13 -04:00
|
|
|
unlock tables;
|
|
|
|
connection writer;
|
|
|
|
reap;
|
|
|
|
connection reader;
|
|
|
|
reap;
|
|
|
|
connection locker;
|
|
|
|
drop table t1;
|
|
|
|
|
2009-04-03 16:11:54 -03:00
|
|
|
#
|
|
|
|
# Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely
|
|
|
|
#
|
|
|
|
|
|
|
|
connect (con1,localhost,root,,);
|
|
|
|
connect (con2,localhost,root,,);
|
|
|
|
connect (con3,localhost,root,,);
|
|
|
|
connect (con4,localhost,root,,);
|
|
|
|
connect (con5,localhost,root,,);
|
|
|
|
|
|
|
|
create table t1 (a int);
|
|
|
|
create table t2 like t1;
|
|
|
|
|
|
|
|
connection con1;
|
|
|
|
--echo # con1
|
|
|
|
lock tables t1 write;
|
|
|
|
connection con2;
|
|
|
|
--echo # con2
|
|
|
|
send flush tables with read lock;
|
|
|
|
connection con5;
|
|
|
|
--echo # con5
|
2009-11-30 18:55:03 +03:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock" and
|
|
|
|
info = "flush tables with read lock";
|
2009-11-30 18:55:03 +03:00
|
|
|
--source include/wait_condition.inc
|
2009-04-03 16:11:54 -03:00
|
|
|
--echo # global read lock is taken
|
|
|
|
connection con3;
|
|
|
|
--echo # con3
|
|
|
|
send select * from t2 for update;
|
|
|
|
connection con5;
|
|
|
|
let $show_statement= SHOW PROCESSLIST;
|
|
|
|
let $field= State;
|
|
|
|
let $condition= = 'Waiting for release of readlock';
|
|
|
|
--source include/wait_show_condition.inc
|
|
|
|
--echo # waiting for release of read lock
|
|
|
|
connection con4;
|
|
|
|
--echo # con4
|
|
|
|
--echo # would hang and later cause a deadlock
|
|
|
|
flush tables t2;
|
|
|
|
connection con1;
|
|
|
|
--echo # clean up
|
|
|
|
unlock tables;
|
|
|
|
connection con2;
|
|
|
|
--reap
|
|
|
|
unlock tables;
|
|
|
|
connection con3;
|
|
|
|
--reap
|
|
|
|
connection default;
|
|
|
|
disconnect con5;
|
|
|
|
disconnect con4;
|
|
|
|
disconnect con3;
|
|
|
|
disconnect con2;
|
|
|
|
disconnect con1;
|
|
|
|
|
|
|
|
drop table t1,t2;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Lightweight version:
|
|
|
|
--echo # Ensure that the wait for a GRL is done before opening tables.
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
connect (con1,localhost,root,,);
|
|
|
|
connect (con2,localhost,root,,);
|
|
|
|
|
|
|
|
create table t1 (a int);
|
|
|
|
create table t2 like t1;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # UPDATE
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
connection default;
|
|
|
|
--echo # default
|
|
|
|
flush tables with read lock;
|
|
|
|
connection con1;
|
|
|
|
--echo # con1
|
|
|
|
send update t2 set a = 1;
|
|
|
|
connection default;
|
|
|
|
--echo # default
|
|
|
|
let $show_statement= SHOW PROCESSLIST;
|
|
|
|
let $field= State;
|
|
|
|
let $condition= = 'Waiting for release of readlock';
|
|
|
|
--source include/wait_show_condition.inc
|
|
|
|
--echo # statement is waiting for release of read lock
|
|
|
|
connection con2;
|
|
|
|
--echo # con2
|
|
|
|
flush table t2;
|
|
|
|
connection default;
|
|
|
|
--echo # default
|
|
|
|
unlock tables;
|
|
|
|
connection con1;
|
|
|
|
--echo # con1
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # LOCK TABLES .. WRITE
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
connection default;
|
|
|
|
--echo # default
|
|
|
|
flush tables with read lock;
|
|
|
|
connection con1;
|
|
|
|
--echo # con1
|
|
|
|
send lock tables t2 write;
|
|
|
|
connection default;
|
|
|
|
--echo # default
|
|
|
|
let $show_statement= SHOW PROCESSLIST;
|
|
|
|
let $field= State;
|
|
|
|
let $condition= = 'Waiting for release of readlock';
|
|
|
|
--source include/wait_show_condition.inc
|
|
|
|
--echo # statement is waiting for release of read lock
|
|
|
|
connection con2;
|
|
|
|
--echo # con2
|
|
|
|
flush table t2;
|
|
|
|
connection default;
|
|
|
|
--echo # default
|
|
|
|
unlock tables;
|
|
|
|
connection con1;
|
|
|
|
--echo # con1
|
|
|
|
--reap
|
|
|
|
unlock tables;
|
|
|
|
|
|
|
|
connection default;
|
|
|
|
disconnect con2;
|
|
|
|
disconnect con1;
|
|
|
|
|
|
|
|
drop table t1,t2;
|
|
|
|
|
2008-10-09 20:24:31 +05:00
|
|
|
|
2007-08-11 14:07:49 +04:00
|
|
|
--echo End of 5.0 tests
|
2006-05-24 17:21:35 +03:00
|
|
|
|
2007-08-05 13:55:37 +04:00
|
|
|
|
|
|
|
#
|
2009-03-06 15:56:17 +01:00
|
|
|
# Bug#21281 Pending write lock is incorrectly removed when its
|
|
|
|
# statement being KILLed
|
2007-08-05 13:55:37 +04:00
|
|
|
#
|
|
|
|
create table t1 (i int);
|
|
|
|
connection locker;
|
|
|
|
lock table t1 read;
|
|
|
|
connection writer;
|
2009-03-06 15:56:17 +01:00
|
|
|
send
|
|
|
|
update t1 set i= 10;
|
2007-08-05 13:55:37 +04:00
|
|
|
connection reader;
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table level lock" and
|
|
|
|
info = "update t1 set i= 10";
|
2007-08-05 13:55:37 +04:00
|
|
|
--source include/wait_condition.inc
|
2009-03-06 15:56:17 +01:00
|
|
|
send
|
|
|
|
select * from t1;
|
2007-08-05 13:55:37 +04:00
|
|
|
connection default;
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table level lock" and
|
|
|
|
info = "select * from t1";
|
2007-08-05 13:55:37 +04:00
|
|
|
--source include/wait_condition.inc
|
2010-08-06 15:29:37 +04:00
|
|
|
let $ID= `select id from information_schema.processlist
|
|
|
|
where state = "Waiting for table level lock" and
|
|
|
|
info = "update t1 set i= 10"`;
|
2007-08-05 13:55:37 +04:00
|
|
|
--replace_result $ID ID
|
|
|
|
eval kill query $ID;
|
|
|
|
connection reader;
|
|
|
|
--reap
|
|
|
|
connection writer;
|
2009-03-06 15:56:17 +01:00
|
|
|
--error ER_QUERY_INTERRUPTED
|
2007-08-05 13:55:37 +04:00
|
|
|
--reap
|
|
|
|
connection locker;
|
|
|
|
unlock tables;
|
|
|
|
connection default;
|
|
|
|
drop table t1;
|
|
|
|
|
2007-08-17 11:34:12 -03:00
|
|
|
#
|
2009-03-06 15:56:17 +01:00
|
|
|
# Bug#25856 HANDLER table OPEN in one connection lock DROP TABLE in another one
|
2007-08-17 11:34:12 -03:00
|
|
|
#
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
--enable_warnings
|
|
|
|
create table t1 (a int) ENGINE=MEMORY;
|
|
|
|
--echo --> client 2
|
|
|
|
connection locker;
|
2009-03-06 15:56:17 +01:00
|
|
|
--error ER_ILLEGAL_HA
|
2007-08-17 11:34:12 -03:00
|
|
|
handler t1 open;
|
|
|
|
--echo --> client 1
|
|
|
|
connection default;
|
|
|
|
drop table t1;
|
|
|
|
|
2009-03-06 15:56:17 +01:00
|
|
|
|
|
|
|
# Disconnect sessions used in many subtests above
|
|
|
|
disconnect locker;
|
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
|
|
|
disconnect locker2;
|
2009-03-06 15:56:17 +01:00
|
|
|
disconnect reader;
|
|
|
|
disconnect writer;
|
2009-03-03 21:34:18 +01:00
|
|
|
|
|
|
|
|
2007-12-12 19:44:14 -02:00
|
|
|
#
|
|
|
|
# Bug#32395 Alter table under a impending global read lock causes a server crash
|
|
|
|
#
|
|
|
|
|
|
|
|
#
|
|
|
|
# Test ALTER TABLE under LOCK TABLES and FLUSH TABLES WITH READ LOCK
|
|
|
|
#
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
--enable_warnings
|
|
|
|
create table t1 (i int);
|
|
|
|
connect (flush,localhost,root,,test,,);
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
lock tables t1 write;
|
|
|
|
connection flush;
|
|
|
|
--echo connection: flush
|
|
|
|
--send flush tables with read lock;
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock";
|
2007-12-12 19:44:14 -02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
alter table t1 add column j int;
|
|
|
|
connect (insert,localhost,root,,test,,);
|
|
|
|
connection insert;
|
|
|
|
--echo connection: insert
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock";
|
2007-12-12 19:44:14 -02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
--send insert into t1 values (1,2);
|
|
|
|
--echo connection: default
|
|
|
|
connection default;
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
|
|
|
where state = "Waiting for release of readlock";
|
|
|
|
--source include/wait_condition.inc
|
|
|
|
unlock tables;
|
|
|
|
connection flush;
|
|
|
|
--echo connection: flush
|
|
|
|
--reap
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
|
|
|
where state = "Waiting for release of readlock";
|
|
|
|
--source include/wait_condition.inc
|
|
|
|
select * from t1;
|
|
|
|
unlock tables;
|
|
|
|
connection insert;
|
|
|
|
--reap
|
|
|
|
connection default;
|
2008-02-22 10:35:08 -02:00
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from t1;
|
|
|
|
--source include/wait_condition.inc
|
2007-12-12 19:44:14 -02:00
|
|
|
select * from t1;
|
|
|
|
drop table t1;
|
|
|
|
disconnect flush;
|
|
|
|
disconnect insert;
|
|
|
|
|
|
|
|
#
|
|
|
|
# Test that FLUSH TABLES under LOCK TABLES protects write locked tables
|
|
|
|
# from a impending FLUSH TABLES WITH READ LOCK
|
|
|
|
#
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
--enable_warnings
|
|
|
|
create table t1 (i int);
|
|
|
|
connect (flush,localhost,root,,test,,);
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
lock tables t1 write;
|
|
|
|
connection flush;
|
|
|
|
--echo connection: flush
|
|
|
|
--send flush tables with read lock;
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock";
|
2007-12-12 19:44:14 -02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
flush tables;
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock";
|
2007-12-12 19:44:14 -02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
unlock tables;
|
|
|
|
connection flush;
|
|
|
|
--reap
|
|
|
|
connection default;
|
|
|
|
disconnect flush;
|
|
|
|
drop table t1;
|
|
|
|
|
2008-01-28 10:52:41 -02:00
|
|
|
#
|
2009-03-06 15:56:17 +01:00
|
|
|
# Bug#30331 Table_locks_waited shows inaccurate values
|
2008-01-28 10:52:41 -02:00
|
|
|
#
|
2008-02-06 09:40:59 -02:00
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1,t2;
|
|
|
|
--enable_warnings
|
|
|
|
create table t1 (a int);
|
|
|
|
flush status;
|
|
|
|
lock tables t1 read;
|
|
|
|
let $tlwa= `show status like 'Table_locks_waited'`;
|
|
|
|
connect (waiter,localhost,root,,);
|
|
|
|
connection waiter;
|
2009-12-03 23:08:27 +03:00
|
|
|
send insert into t1 values(1);
|
2008-02-06 09:40:59 -02:00
|
|
|
connection default;
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for table level lock" and
|
|
|
|
info = "insert into t1 values(1)";
|
2008-02-06 09:40:59 -02:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
let $tlwb= `show status like 'Table_locks_waited'`;
|
|
|
|
unlock tables;
|
2009-12-19 08:37:08 +01:00
|
|
|
connection waiter;
|
|
|
|
--reap
|
|
|
|
connection default;
|
2008-02-06 09:40:59 -02:00
|
|
|
drop table t1;
|
|
|
|
disconnect waiter;
|
|
|
|
--disable_query_log
|
|
|
|
eval SET @tlwa= SUBSTRING_INDEX('$tlwa', ' ', -1);
|
|
|
|
eval SET @tlwb= SUBSTRING_INDEX('$tlwb', ' ', -1);
|
|
|
|
--enable_query_log
|
|
|
|
select @tlwa < @tlwb;
|
2008-01-28 10:52:41 -02:00
|
|
|
|
2007-08-05 13:55:37 +04:00
|
|
|
--echo End of 5.1 tests
|
2009-03-03 21:34:18 +01:00
|
|
|
|
2009-11-20 23:12:57 +03:00
|
|
|
#
|
|
|
|
# Test that DROP TABLES does not wait for a impending FLUSH TABLES
|
|
|
|
# WITH READ LOCK
|
|
|
|
#
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
--enable_warnings
|
|
|
|
create table t1 (i int);
|
|
|
|
connect (flush,localhost,root,,test,,);
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
lock tables t1 write;
|
|
|
|
connection flush;
|
|
|
|
--echo connection: flush
|
|
|
|
--send flush tables with read lock;
|
|
|
|
connection default;
|
|
|
|
--echo connection: default
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock";
|
2009-11-20 23:12:57 +03:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
flush tables;
|
|
|
|
let $wait_condition=
|
|
|
|
select count(*) = 1 from information_schema.processlist
|
2010-08-06 15:29:37 +04:00
|
|
|
where state = "Waiting for global metadata lock";
|
2009-11-20 23:12:57 +03:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
drop table t1;
|
|
|
|
connection flush;
|
|
|
|
--reap
|
|
|
|
connection default;
|
|
|
|
disconnect flush;
|
2009-12-09 10:44:01 +01:00
|
|
|
|
|
|
|
|
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 #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock".
|
|
|
|
--echo #
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
--enable_warnings
|
|
|
|
create table t1 (c1 int primary key, c2 int, c3 int);
|
|
|
|
insert into t1 values (1,1,0),(2,2,0),(3,3,0),(4,4,0),(5,5,0);
|
|
|
|
begin;
|
|
|
|
update t1 set c3=c3+1 where c2=3;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Switching to connection 'con46272'.
|
|
|
|
connect (con46272,localhost,root,,test,,);
|
|
|
|
connection con46272;
|
|
|
|
--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 'con46272'.
|
|
|
|
connection con46272;
|
|
|
|
--echo # Reaping ALTER TABLE.
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Switching to connection 'default'.
|
|
|
|
connection default;
|
|
|
|
disconnect con46272;
|
|
|
|
drop table t1;
|
|
|
|
|
|
|
|
|
2009-12-09 10:44:01 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Bug#47249 assert in MDL_global_lock::is_lock_type_compatible
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
DROP VIEW IF EXISTS v1;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 1: LOCK TABLES v1 WRITE, t1 READ;
|
|
|
|
--echo #
|
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 # Thanks to the fact that we no longer allow DDL on tables
|
|
|
|
--echo # which are locked for write implicitly, the exact scenario
|
|
|
|
--echo # in which assert was failing is no longer repeatable.
|
2009-12-09 10:44:01 +01:00
|
|
|
|
|
|
|
CREATE TABLE t1 ( f1 integer );
|
|
|
|
CREATE VIEW v1 AS SELECT f1 FROM t1 ;
|
|
|
|
|
|
|
|
LOCK TABLES v1 WRITE, t1 READ;
|
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
|
|
|
--error ER_TABLE_NOT_LOCKED_FOR_WRITE
|
2009-12-09 10:44:01 +01:00
|
|
|
FLUSH TABLE t1;
|
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
|
|
|
UNLOCK TABLES;
|
2009-12-09 10:44:01 +01:00
|
|
|
|
|
|
|
# Cleanup
|
|
|
|
DROP TABLE t1;
|
|
|
|
DROP VIEW v1;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 2: LOCK TABLES t1 WRITE, v1 READ;
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
CREATE TABLE t1 ( f1 integer );
|
|
|
|
CREATE VIEW v1 AS SELECT f1 FROM t1 ;
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connect (con2,localhost,root);
|
|
|
|
LOCK TABLES t1 WRITE, v1 READ;
|
|
|
|
FLUSH TABLE t1;
|
|
|
|
disconnect con2;
|
|
|
|
--source include/wait_until_disconnected.inc
|
|
|
|
|
|
|
|
--echo # Connection 1
|
|
|
|
connection default;
|
|
|
|
LOCK TABLES t1 WRITE;
|
|
|
|
FLUSH TABLE t1; # Assertion happened here
|
|
|
|
|
|
|
|
# Cleanup
|
|
|
|
DROP TABLE t1;
|
|
|
|
DROP VIEW v1;
|
|
|
|
|
|
|
|
|
2010-02-08 23:19:55 +03:00
|
|
|
--echo #
|
|
|
|
--echo # Test for bug #50913 "Deadlock between open_and_lock_tables_derived
|
|
|
|
--echo # and MDL". Also see additional coverage in mdl_sync.test.
|
|
|
|
--echo #
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
drop view if exists v1;
|
|
|
|
--enable_warnings
|
|
|
|
connect (con50913,localhost,root);
|
|
|
|
connection default;
|
|
|
|
create table t1 (i int);
|
|
|
|
create view v1 as select i from t1;
|
|
|
|
begin;
|
|
|
|
select * from t1;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con50913'.
|
|
|
|
connection con50913;
|
|
|
|
--echo # Sending:
|
|
|
|
--send alter table t1 add column j int
|
|
|
|
|
|
|
|
--echo # Switching to connection 'default'.
|
|
|
|
connection default;
|
|
|
|
--echo # Wait until ALTER TABLE gets blocked.
|
|
|
|
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 j int";
|
2010-02-08 23:19:55 +03:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
--echo # The below statement should try to acquire SW lock on 't1'
|
|
|
|
--echo # and therefore should get ER_LOCK_DEADLOCK error. Before
|
|
|
|
--echo # bug fix it acquired SR lock and hung on thr_lock.c lock.
|
|
|
|
--error ER_LOCK_DEADLOCK
|
|
|
|
delete a from t1 as a where i = 1;
|
|
|
|
--echo # Unblock ALTER TABLE.
|
|
|
|
commit;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con50913'.
|
|
|
|
connection con50913;
|
|
|
|
--echo # Reaping ALTER TABLE;
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo # Switching to connection 'default'.
|
|
|
|
connection default;
|
|
|
|
begin;
|
|
|
|
select * from v1;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con50913'.
|
|
|
|
connection con50913;
|
|
|
|
--echo # Sending:
|
|
|
|
--send alter table t1 drop column j
|
|
|
|
|
|
|
|
--echo # Switching to connection 'default'.
|
|
|
|
connection default;
|
|
|
|
--echo # Wait until ALTER TABLE gets blocked.
|
|
|
|
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 drop column j";
|
2010-02-08 23:19:55 +03:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
--echo # The below statement should try to acquire SW lock on 't1'
|
|
|
|
--echo # and therefore should get ER_LOCK_DEADLOCK error. Before
|
|
|
|
--echo # bug fix it acquired SR lock and hung on thr_lock.c lock.
|
|
|
|
--error ER_LOCK_DEADLOCK
|
|
|
|
insert into v1 values (1);
|
|
|
|
--echo # Unblock ALTER TABLE.
|
|
|
|
commit;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con50913'.
|
|
|
|
connection con50913;
|
|
|
|
--echo # Reaping ALTER TABLE;
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo # Switching to connection 'default'.
|
|
|
|
connection default;
|
|
|
|
disconnect con50913;
|
|
|
|
drop view v1;
|
|
|
|
drop table t1;
|
|
|
|
|
|
|
|
|
2010-02-11 11:23:39 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Bug#45225 Locking: hang if drop table with no timeout
|
|
|
|
--echo #
|
|
|
|
--echo # These tests also provide function coverage for the
|
|
|
|
--echo # lock_wait_timeout server variable.
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
CREATE TABLE t1 (id int);
|
|
|
|
|
|
|
|
connect(con2, localhost, root,,);
|
|
|
|
SET SESSION lock_wait_timeout= 1;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 1: acquire exclusive lock
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
START TRANSACTION;
|
|
|
|
INSERT INTO t1 VALUES (1);
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connection con2;
|
|
|
|
--error ER_LOCK_WAIT_TIMEOUT
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
COMMIT;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 2: upgrade shared lock
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
START TRANSACTION;
|
|
|
|
SELECT * FROM t1;
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connection con2;
|
|
|
|
--error ER_LOCK_WAIT_TIMEOUT
|
|
|
|
ALTER TABLE t1 RENAME TO t2;
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
COMMIT;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 3: acquire shared lock
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
LOCK TABLE t1 WRITE;
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connection con2;
|
|
|
|
--error ER_LOCK_WAIT_TIMEOUT
|
|
|
|
INSERT INTO t1(id) VALUES (2);
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 4: table level locks
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
LOCK TABLE t1 READ;
|
|
|
|
|
|
|
|
--echo # Connection 2
|
|
|
|
connection con2;
|
|
|
|
--error ER_LOCK_WAIT_TIMEOUT
|
|
|
|
INSERT INTO t1(id) VALUES(4);
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 5: Waiting on Table Definition Cache (TDC)
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
connect(con3, localhost, root);
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
LOCK TABLE t1 READ;
|
|
|
|
|
|
|
|
--echo # Connection con3
|
|
|
|
connection con3;
|
|
|
|
--echo # Sending:
|
|
|
|
--send FLUSH TABLES
|
|
|
|
|
|
|
|
--echo # Connection con2
|
|
|
|
connection con2;
|
|
|
|
let $wait_condition=
|
|
|
|
SELECT COUNT(*) = 1 FROM information_schema.processlist
|
2010-08-12 17:50:23 +04:00
|
|
|
WHERE state = "Waiting for table flush" AND info = "FLUSH TABLES";
|
2010-02-11 11:23:39 +01:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
--error ER_LOCK_WAIT_TIMEOUT
|
|
|
|
SELECT * FROM t1;
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
|
|
|
--echo # Connection con3
|
|
|
|
connection con3;
|
|
|
|
--echo # Reaping: FLUSH TABLES
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Test 6: Timeouts in I_S queries
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
CREATE TABLE t2 (id INT);
|
|
|
|
LOCK TABLE t2 WRITE;
|
|
|
|
|
|
|
|
--echo # Connection con3
|
|
|
|
connection con3;
|
|
|
|
--echo # Sending:
|
|
|
|
--send DROP TABLE t1, t2
|
|
|
|
|
|
|
|
--echo # Connection con2
|
|
|
|
connection con2;
|
|
|
|
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 = "DROP TABLE t1, t2";
|
2010-02-11 11:23:39 +01:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
# Note: This query causes two timeouts.
|
|
|
|
# 1: try_acquire_high_prio_shared_mdl_lock on t1
|
|
|
|
# 2: recover_from_failed_open on t1
|
|
|
|
SELECT table_name, table_comment FROM information_schema.tables
|
|
|
|
WHERE table_schema= 'test' AND table_name= 't1';
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
|
|
|
--echo # Connection con3
|
|
|
|
connection con3;
|
|
|
|
--echo # Reaping: DROP TABLE t1, t2
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
--echo # Cleanup
|
|
|
|
disconnect con2;
|
|
|
|
disconnect con3;
|
|
|
|
|
|
|
|
|
2010-02-15 13:23:34 +03:00
|
|
|
--echo #
|
|
|
|
--echo # Test for bug #51134 "Crash in MDL_lock::destroy on a concurrent
|
|
|
|
--echo # DDL workload".
|
|
|
|
--echo #
|
|
|
|
--disable_warnings
|
|
|
|
drop tables if exists t1, t2, t3;
|
|
|
|
--enable_warnings
|
|
|
|
connect (con1, localhost, root, , );
|
|
|
|
connect (con2, localhost, root, , );
|
|
|
|
connection default;
|
|
|
|
create table t3 (i int);
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con1'
|
|
|
|
connection con1;
|
|
|
|
--echo # Lock 't3' so upcoming RENAME is blocked.
|
|
|
|
lock table t3 read;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con2'
|
|
|
|
connection con2;
|
|
|
|
--echo # Remember ID for this connection.
|
|
|
|
let $ID= `select connection_id()`;
|
|
|
|
--echo # Start statement which will try to acquire two instances
|
|
|
|
--echo # of X metadata lock on the same object.
|
|
|
|
--echo # Sending:
|
|
|
|
--send rename tables t1 to t2, t2 to t3;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'default'
|
|
|
|
connection default;
|
|
|
|
--echo # Wait until RENAME TABLE is blocked on table 't3'.
|
|
|
|
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 = "rename tables t1 to t2, t2 to t3";
|
2010-02-15 13:23:34 +03:00
|
|
|
--source include/wait_condition.inc
|
|
|
|
--echo # Kill RENAME TABLE.
|
|
|
|
--replace_result $ID ID
|
|
|
|
eval kill query $ID;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con2'
|
|
|
|
connection con2;
|
|
|
|
--echo # RENAME TABLE should be aborted but should not crash.
|
|
|
|
--error ER_QUERY_INTERRUPTED
|
|
|
|
--reap
|
|
|
|
|
|
|
|
--echo # Switching to connection 'con1'
|
|
|
|
connection con1;
|
|
|
|
unlock tables;
|
|
|
|
|
|
|
|
--echo # Switching to connection 'default'
|
|
|
|
connection default;
|
|
|
|
disconnect con1;
|
|
|
|
disconnect con2;
|
|
|
|
drop table t3;
|
|
|
|
|
|
|
|
|
2010-02-26 13:40:25 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Test for the bug where upgradable metadata locks was acquired
|
|
|
|
--echo # even if the table to altered was temporary.
|
|
|
|
--echo # Bug found while working on the related bug #51240.
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
CREATE TABLE t1 (id INT);
|
|
|
|
LOCK TABLE t1 WRITE;
|
|
|
|
|
|
|
|
--echo # Connection con1
|
|
|
|
connect (con1, localhost, root);
|
|
|
|
CREATE TEMPORARY TABLE t1 (id INT);
|
|
|
|
# This alter should not block and timeout.
|
|
|
|
ALTER TABLE t1 ADD COLUMN j INT;
|
|
|
|
|
|
|
|
--echo # Connection default
|
|
|
|
connection default;
|
|
|
|
disconnect con1;
|
|
|
|
UNLOCK TABLES;
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
|
|
|
|
2009-03-03 21:34:18 +01:00
|
|
|
# Wait till all disconnects are completed
|
|
|
|
--source include/wait_until_count_sessions.inc
|