2003-03-04 11:22:35 +01:00
|
|
|
drop table if exists t1,t2;
|
2001-10-08 06:24:04 +02:00
|
|
|
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 12:43:06 +01:00
|
|
|
select get_lock("mysqltest_lock", 100);
|
|
|
|
|
get_lock("mysqltest_lock", 100)
|
|
|
|
|
1
|
|
|
|
|
update t1 set n = 2 and get_lock('mysqltest_lock', 100);
|
2006-10-04 23:48:24 +02:00
|
|
|
update low_priority t1 set n = 4;
|
|
|
|
|
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 12:43:06 +01:00
|
|
|
select release_lock("mysqltest_lock");
|
|
|
|
|
release_lock("mysqltest_lock")
|
|
|
|
|
1
|
|
|
|
|
select release_lock("mysqltest_lock");
|
|
|
|
|
release_lock("mysqltest_lock")
|
|
|
|
|
1
|
2001-10-08 03:58:07 +02:00
|
|
|
n
|
|
|
|
|
4
|
2001-10-08 06:24:04 +02:00
|
|
|
drop table t1;
|
|
|
|
|
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 12:43:06 +01:00
|
|
|
select get_lock("mysqltest_lock", 100);
|
|
|
|
|
get_lock("mysqltest_lock", 100)
|
|
|
|
|
1
|
|
|
|
|
select n from t1 where get_lock('mysqltest_lock', 100);
|
2006-10-04 23:48:24 +02:00
|
|
|
update low_priority t1 set n = 4;
|
|
|
|
|
select n from t1;
|
2001-10-08 03:58:07 +02:00
|
|
|
n
|
|
|
|
|
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 12:43:06 +01:00
|
|
|
select release_lock("mysqltest_lock");
|
|
|
|
|
release_lock("mysqltest_lock")
|
|
|
|
|
1
|
|
|
|
|
n
|
|
|
|
|
1
|
|
|
|
|
select release_lock("mysqltest_lock");
|
|
|
|
|
release_lock("mysqltest_lock")
|
|
|
|
|
1
|
2001-10-08 06:24:04 +02:00
|
|
|
drop table t1;
|
2004-10-03 01:20:47 +02:00
|
|
|
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;
|
2006-10-04 23:48:24 +02:00
|
|
|
update t1,t2 set c=a where b=d;
|
2004-10-03 01:20:47 +02:00
|
|
|
select c from t2;
|
|
|
|
|
c
|
2004-11-05 16:29:47 +01:00
|
|
|
2
|
2009-11-20 20:51:12 +01:00
|
|
|
unlock tables;
|
2004-10-03 01:20:47 +02:00
|
|
|
drop table t1;
|
|
|
|
|
drop table t2;
|
2003-03-04 11:22:35 +01:00
|
|
|
create table t1 (a int);
|
|
|
|
|
create table t2 (a int);
|
|
|
|
|
lock table t1 write, t2 write;
|
2006-10-04 23:48:24 +02:00
|
|
|
insert t1 select * from t2;
|
2003-03-04 11:22:35 +01: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 12:43:06 +01:00
|
|
|
unlock tables;
|
2003-06-04 17:28:51 +02:00
|
|
|
ERROR 42S02: Table 'test.t2' doesn't exist
|
2003-03-04 11:22:35 +01:00
|
|
|
drop table t1;
|
2006-03-29 13:27:36 +02:00
|
|
|
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;
|
2006-10-05 00:36:03 +02:00
|
|
|
insert t1 select * from t2;
|
2006-03-29 13:27:36 +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 12:43:06 +01:00
|
|
|
unlock tables;
|
2006-03-29 13:27:36 +02:00
|
|
|
ERROR 42S02: Table 'test.t2' doesn't exist
|
|
|
|
|
drop table t1;
|
2007-08-11 12:07:49 +02:00
|
|
|
End of 4.1 tests
|
2005-06-03 15:29:05 +02:00
|
|
|
create table t1(a int);
|
|
|
|
|
lock tables t1 write;
|
|
|
|
|
show columns from t1;
|
|
|
|
|
Field Type Null Key Default Extra
|
|
|
|
|
a int(11) YES NULL
|
|
|
|
|
unlock tables;
|
|
|
|
|
drop table t1;
|
2009-03-03 21:34:18 +01:00
|
|
|
USE mysql;
|
2006-05-24 16:21:35 +02:00
|
|
|
LOCK TABLES columns_priv WRITE, db WRITE, host WRITE, user WRITE;
|
|
|
|
|
FLUSH TABLES;
|
2009-03-03 21:34:18 +01:00
|
|
|
USE mysql;
|
2006-10-04 23:48:24 +02:00
|
|
|
SELECT user.Select_priv FROM user, db WHERE user.user = db.user LIMIT 1;
|
2006-05-24 16:21:35 +02:00
|
|
|
OPTIMIZE TABLES columns_priv, db, host, user;
|
|
|
|
|
Table Op Msg_type Msg_text
|
|
|
|
|
mysql.columns_priv optimize status OK
|
|
|
|
|
mysql.db optimize status OK
|
|
|
|
|
mysql.host optimize status OK
|
|
|
|
|
mysql.user optimize status OK
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
Select_priv
|
|
|
|
|
N
|
2009-03-03 21:34:18 +01:00
|
|
|
USE test;
|
2006-05-24 16:21:35 +02:00
|
|
|
use test;
|
2006-06-26 19:14:35 +02:00
|
|
|
CREATE TABLE t1 (c1 int);
|
|
|
|
|
LOCK TABLE t1 WRITE;
|
2006-10-04 23:48:24 +02:00
|
|
|
FLUSH TABLES WITH READ LOCK;
|
2006-06-26 19:14:35 +02:00
|
|
|
CREATE TABLE t2 (c1 int);
|
2009-12-10 11:53:20 +01:00
|
|
|
ERROR HY000: Table 't2' was not locked with LOCK TABLES
|
2006-06-26 19:14:35 +02:00
|
|
|
UNLOCK TABLES;
|
|
|
|
|
UNLOCK TABLES;
|
2009-12-10 11:53:20 +01:00
|
|
|
DROP TABLE t1;
|
2006-06-26 19:14:35 +02:00
|
|
|
CREATE TABLE t1 (c1 int);
|
|
|
|
|
LOCK TABLE t1 WRITE;
|
2006-10-04 23:48:24 +02:00
|
|
|
FLUSH TABLES WITH READ LOCK;
|
2006-06-26 19:14:35 +02:00
|
|
|
CREATE TABLE t2 AS SELECT * FROM t1;
|
|
|
|
|
ERROR HY000: Table 't2' was not locked with LOCK TABLES
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
DROP TABLE t1;
|
2006-05-29 15:26:23 +02:00
|
|
|
CREATE DATABASE mysqltest_1;
|
|
|
|
|
FLUSH TABLES WITH READ LOCK;
|
2006-10-04 23:48:24 +02:00
|
|
|
DROP DATABASE mysqltest_1;
|
2006-05-29 15:26:23 +02:00
|
|
|
DROP DATABASE mysqltest_1;
|
|
|
|
|
ERROR HY000: Can't execute the query because you have a conflicting read lock
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
DROP DATABASE mysqltest_1;
|
|
|
|
|
ERROR HY000: Can't drop database 'mysqltest_1'; database doesn't exist
|
2006-06-20 19:43:13 +02:00
|
|
|
create table t1 (f1 int(12) unsigned not null auto_increment, primary key(f1)) engine=innodb;
|
|
|
|
|
lock tables t1 write;
|
2007-08-11 12:07:49 +02:00
|
|
|
alter table t1 auto_increment=0;
|
|
|
|
|
alter table t1 auto_increment=0;
|
2006-06-20 19:43:13 +02:00
|
|
|
unlock tables;
|
|
|
|
|
drop table t1;
|
2009-04-03 21:11:54 +02:00
|
|
|
create table t1 (a int);
|
|
|
|
|
create table t2 like t1;
|
|
|
|
|
# con1
|
|
|
|
|
lock tables t1 write;
|
|
|
|
|
# con2
|
|
|
|
|
flush tables with read lock;
|
|
|
|
|
# con5
|
|
|
|
|
# global read lock is taken
|
|
|
|
|
# con3
|
|
|
|
|
select * from t2 for update;
|
|
|
|
|
# waiting for release of read lock
|
|
|
|
|
# con4
|
|
|
|
|
# would hang and later cause a deadlock
|
|
|
|
|
flush tables t2;
|
|
|
|
|
# clean up
|
|
|
|
|
unlock tables;
|
|
|
|
|
unlock tables;
|
|
|
|
|
a
|
|
|
|
|
drop table t1,t2;
|
|
|
|
|
#
|
|
|
|
|
# Lightweight version:
|
|
|
|
|
# Ensure that the wait for a GRL is done before opening tables.
|
|
|
|
|
#
|
|
|
|
|
create table t1 (a int);
|
|
|
|
|
create table t2 like t1;
|
|
|
|
|
#
|
|
|
|
|
# UPDATE
|
|
|
|
|
#
|
|
|
|
|
# default
|
|
|
|
|
flush tables with read lock;
|
|
|
|
|
# con1
|
|
|
|
|
update t2 set a = 1;
|
|
|
|
|
# default
|
|
|
|
|
# statement is waiting for release of read lock
|
|
|
|
|
# con2
|
|
|
|
|
flush table t2;
|
|
|
|
|
# default
|
|
|
|
|
unlock tables;
|
|
|
|
|
# con1
|
|
|
|
|
#
|
|
|
|
|
# LOCK TABLES .. WRITE
|
|
|
|
|
#
|
|
|
|
|
# default
|
|
|
|
|
flush tables with read lock;
|
|
|
|
|
# con1
|
|
|
|
|
lock tables t2 write;
|
|
|
|
|
# default
|
|
|
|
|
# statement is waiting for release of read lock
|
|
|
|
|
# con2
|
|
|
|
|
flush table t2;
|
|
|
|
|
# default
|
|
|
|
|
unlock tables;
|
|
|
|
|
# con1
|
|
|
|
|
unlock tables;
|
|
|
|
|
drop table t1,t2;
|
2007-08-11 12:07:49 +02:00
|
|
|
End of 5.0 tests
|
2007-08-05 11:55:37 +02:00
|
|
|
create table t1 (i int);
|
|
|
|
|
lock table t1 read;
|
2009-03-06 15:56:17 +01:00
|
|
|
update t1 set i= 10;
|
|
|
|
|
select * from t1;
|
2007-08-05 11:55:37 +02:00
|
|
|
kill query ID;
|
|
|
|
|
i
|
|
|
|
|
ERROR 70100: Query execution was interrupted
|
|
|
|
|
unlock tables;
|
|
|
|
|
drop table t1;
|
2007-08-17 16:34:12 +02:00
|
|
|
drop table if exists t1;
|
|
|
|
|
create table t1 (a int) ENGINE=MEMORY;
|
|
|
|
|
--> client 2
|
|
|
|
|
handler t1 open;
|
|
|
|
|
ERROR HY000: Table storage engine for 't1' doesn't have this option
|
|
|
|
|
--> client 1
|
|
|
|
|
drop table t1;
|
2007-12-12 22:44:14 +01:00
|
|
|
drop table if exists t1;
|
|
|
|
|
create table t1 (i int);
|
|
|
|
|
connection: default
|
|
|
|
|
lock tables t1 write;
|
|
|
|
|
connection: flush
|
|
|
|
|
flush tables with read lock;;
|
|
|
|
|
connection: default
|
|
|
|
|
alter table t1 add column j int;
|
|
|
|
|
connection: insert
|
|
|
|
|
insert into t1 values (1,2);;
|
|
|
|
|
connection: default
|
|
|
|
|
unlock tables;
|
|
|
|
|
connection: flush
|
|
|
|
|
select * from t1;
|
|
|
|
|
i j
|
|
|
|
|
unlock tables;
|
|
|
|
|
select * from t1;
|
|
|
|
|
i j
|
|
|
|
|
1 2
|
|
|
|
|
drop table t1;
|
|
|
|
|
drop table if exists t1;
|
|
|
|
|
create table t1 (i int);
|
|
|
|
|
connection: default
|
|
|
|
|
lock tables t1 write;
|
|
|
|
|
connection: flush
|
|
|
|
|
flush tables with read lock;;
|
|
|
|
|
connection: default
|
|
|
|
|
flush tables;
|
|
|
|
|
unlock tables;
|
|
|
|
|
drop table t1;
|
2008-01-28 13:52:41 +01:00
|
|
|
drop table if exists t1,t2;
|
|
|
|
|
create table t1 (a int);
|
|
|
|
|
flush status;
|
|
|
|
|
lock tables t1 read;
|
2009-12-03 21:08:27 +01:00
|
|
|
insert into t1 values(1);
|
2008-01-29 13:37:44 +01:00
|
|
|
unlock tables;
|
2008-01-28 13:52:41 +01:00
|
|
|
drop table t1;
|
2008-01-29 13:37:44 +01:00
|
|
|
select @tlwa < @tlwb;
|
|
|
|
|
@tlwa < @tlwb
|
|
|
|
|
1
|
2007-08-05 11:55:37 +02:00
|
|
|
End of 5.1 tests
|
2009-11-20 21:12:57 +01:00
|
|
|
drop table if exists t1;
|
|
|
|
|
create table t1 (i int);
|
|
|
|
|
connection: default
|
|
|
|
|
lock tables t1 write;
|
|
|
|
|
connection: flush
|
|
|
|
|
flush tables with read lock;;
|
|
|
|
|
connection: default
|
|
|
|
|
flush tables;
|
|
|
|
|
drop table t1;
|
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 12:43:06 +01:00
|
|
|
# Test for bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock".
|
|
|
|
|
#
|
|
|
|
|
drop table if exists t1;
|
|
|
|
|
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;
|
|
|
|
|
#
|
|
|
|
|
# Switching to connection 'con46272'.
|
|
|
|
|
# The below ALTER TABLE statement should wait till transaction
|
|
|
|
|
# in connection 'default' is complete and then succeed.
|
|
|
|
|
# It should not deadlock or fail with ER_LOCK_DEADLOCK error.
|
|
|
|
|
# Sending:
|
|
|
|
|
alter table t1 add column c4 int;;
|
|
|
|
|
#
|
|
|
|
|
# Switching to connection 'default'.
|
|
|
|
|
# Wait until the above ALTER TABLE gets blocked because this
|
|
|
|
|
# connection holds SW metadata lock on table to be altered.
|
|
|
|
|
# The below statement should succeed. It should not
|
|
|
|
|
# deadlock or end with ER_LOCK_DEADLOCK error.
|
|
|
|
|
update t1 set c3=c3+1 where c2=4;
|
|
|
|
|
# Unblock ALTER TABLE by committing transaction.
|
|
|
|
|
commit;
|
|
|
|
|
#
|
|
|
|
|
# Switching to connection 'con46272'.
|
|
|
|
|
# Reaping ALTER TABLE.
|
|
|
|
|
#
|
|
|
|
|
# Switching to connection 'default'.
|
|
|
|
|
drop table t1;
|
|
|
|
|
#
|
2009-12-09 10:44:01 +01:00
|
|
|
# Bug#47249 assert in MDL_global_lock::is_lock_type_compatible
|
|
|
|
|
#
|
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
|
DROP VIEW IF EXISTS v1;
|
|
|
|
|
#
|
|
|
|
|
# Test 1: 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 12:43:06 +01:00
|
|
|
# Thanks to the fact that we no longer allow DDL on tables
|
|
|
|
|
# which are locked for write implicitly, the exact scenario
|
|
|
|
|
# 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;
|
|
|
|
|
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 12:43:06 +01:00
|
|
|
ERROR HY000: Table 't1' was locked with a READ lock and can't be updated
|
|
|
|
|
UNLOCK TABLES;
|
2009-12-09 10:44:01 +01:00
|
|
|
DROP TABLE t1;
|
|
|
|
|
DROP VIEW v1;
|
|
|
|
|
#
|
|
|
|
|
# Test 2: LOCK TABLES t1 WRITE, v1 READ;
|
|
|
|
|
#
|
|
|
|
|
CREATE TABLE t1 ( f1 integer );
|
|
|
|
|
CREATE VIEW v1 AS SELECT f1 FROM t1 ;
|
|
|
|
|
# Connection 2
|
|
|
|
|
LOCK TABLES t1 WRITE, v1 READ;
|
|
|
|
|
FLUSH TABLE t1;
|
|
|
|
|
# Connection 1
|
|
|
|
|
LOCK TABLES t1 WRITE;
|
|
|
|
|
FLUSH TABLE t1;
|
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
DROP VIEW v1;
|
2010-02-08 21:19:55 +01:00
|
|
|
#
|
|
|
|
|
# Test for bug #50913 "Deadlock between open_and_lock_tables_derived
|
|
|
|
|
# and MDL". Also see additional coverage in mdl_sync.test.
|
|
|
|
|
#
|
|
|
|
|
drop table if exists t1;
|
|
|
|
|
drop view if exists v1;
|
|
|
|
|
create table t1 (i int);
|
|
|
|
|
create view v1 as select i from t1;
|
|
|
|
|
begin;
|
|
|
|
|
select * from t1;
|
|
|
|
|
i
|
|
|
|
|
# Switching to connection 'con50913'.
|
|
|
|
|
# Sending:
|
|
|
|
|
alter table t1 add column j int;
|
|
|
|
|
# Switching to connection 'default'.
|
|
|
|
|
# Wait until ALTER TABLE gets blocked.
|
|
|
|
|
# The below statement should try to acquire SW lock on 't1'
|
|
|
|
|
# and therefore should get ER_LOCK_DEADLOCK error. Before
|
|
|
|
|
# bug fix it acquired SR lock and hung on thr_lock.c lock.
|
|
|
|
|
delete a from t1 as a where i = 1;
|
|
|
|
|
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
|
|
|
|
|
# Unblock ALTER TABLE.
|
|
|
|
|
commit;
|
|
|
|
|
# Switching to connection 'con50913'.
|
|
|
|
|
# Reaping ALTER TABLE;
|
|
|
|
|
# Switching to connection 'default'.
|
|
|
|
|
begin;
|
|
|
|
|
select * from v1;
|
|
|
|
|
i
|
|
|
|
|
# Switching to connection 'con50913'.
|
|
|
|
|
# Sending:
|
|
|
|
|
alter table t1 drop column j;
|
|
|
|
|
# Switching to connection 'default'.
|
|
|
|
|
# Wait until ALTER TABLE gets blocked.
|
|
|
|
|
# The below statement should try to acquire SW lock on 't1'
|
|
|
|
|
# and therefore should get ER_LOCK_DEADLOCK error. Before
|
|
|
|
|
# bug fix it acquired SR lock and hung on thr_lock.c lock.
|
|
|
|
|
insert into v1 values (1);
|
|
|
|
|
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
|
|
|
|
|
# Unblock ALTER TABLE.
|
|
|
|
|
commit;
|
|
|
|
|
# Switching to connection 'con50913'.
|
|
|
|
|
# Reaping ALTER TABLE;
|
|
|
|
|
# Switching to connection 'default'.
|
|
|
|
|
drop view v1;
|
|
|
|
|
drop table t1;
|
2010-02-11 11:23:39 +01:00
|
|
|
#
|
|
|
|
|
# Bug#45225 Locking: hang if drop table with no timeout
|
|
|
|
|
#
|
|
|
|
|
# These tests also provide function coverage for the
|
|
|
|
|
# lock_wait_timeout server variable.
|
|
|
|
|
#
|
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
|
CREATE TABLE t1 (id int);
|
|
|
|
|
SET SESSION lock_wait_timeout= 1;
|
|
|
|
|
#
|
|
|
|
|
# Test 1: acquire exclusive lock
|
|
|
|
|
#
|
|
|
|
|
# Connection default
|
|
|
|
|
START TRANSACTION;
|
|
|
|
|
INSERT INTO t1 VALUES (1);
|
|
|
|
|
# Connection 2
|
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
|
|
|
|
|
# Connection default
|
|
|
|
|
COMMIT;
|
|
|
|
|
#
|
|
|
|
|
# Test 2: upgrade shared lock
|
|
|
|
|
#
|
|
|
|
|
# Connection default
|
|
|
|
|
START TRANSACTION;
|
|
|
|
|
SELECT * FROM t1;
|
|
|
|
|
id
|
|
|
|
|
1
|
|
|
|
|
# Connection 2
|
|
|
|
|
ALTER TABLE t1 RENAME TO t2;
|
|
|
|
|
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
|
|
|
|
|
# Connection default
|
|
|
|
|
COMMIT;
|
|
|
|
|
#
|
|
|
|
|
# Test 3: acquire shared lock
|
|
|
|
|
#
|
|
|
|
|
# Connection default
|
|
|
|
|
LOCK TABLE t1 WRITE;
|
|
|
|
|
# Connection 2
|
|
|
|
|
INSERT INTO t1(id) VALUES (2);
|
|
|
|
|
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
|
|
|
|
|
# Connection default
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
#
|
|
|
|
|
# Test 4: table level locks
|
|
|
|
|
#
|
|
|
|
|
# Connection default
|
|
|
|
|
LOCK TABLE t1 READ;
|
|
|
|
|
# Connection 2
|
|
|
|
|
INSERT INTO t1(id) VALUES(4);
|
|
|
|
|
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
|
|
|
|
|
# Connection default
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
#
|
|
|
|
|
# Test 5: Waiting on Table Definition Cache (TDC)
|
|
|
|
|
#
|
|
|
|
|
# Connection default
|
|
|
|
|
LOCK TABLE t1 READ;
|
|
|
|
|
# Connection con3
|
|
|
|
|
# Sending:
|
|
|
|
|
FLUSH TABLES;
|
|
|
|
|
# Connection con2
|
|
|
|
|
SELECT * FROM t1;
|
|
|
|
|
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
|
|
|
|
|
# Connection default
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
# Connection con3
|
|
|
|
|
# Reaping: FLUSH TABLES
|
|
|
|
|
#
|
|
|
|
|
# Test 6: Timeouts in I_S queries
|
|
|
|
|
#
|
|
|
|
|
# Connection default
|
|
|
|
|
CREATE TABLE t2 (id INT);
|
|
|
|
|
LOCK TABLE t2 WRITE;
|
|
|
|
|
# Connection con3
|
|
|
|
|
# Sending:
|
|
|
|
|
DROP TABLE t1, t2;
|
|
|
|
|
# Connection con2
|
|
|
|
|
SELECT table_name, table_comment FROM information_schema.tables
|
|
|
|
|
WHERE table_schema= 'test' AND table_name= 't1';
|
|
|
|
|
table_name table_comment
|
|
|
|
|
t1 Lock wait timeout exceeded; try restarting transaction
|
|
|
|
|
# Connection default
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
# Connection con3
|
|
|
|
|
# Reaping: DROP TABLE t1, t2
|
|
|
|
|
# Connection default
|
|
|
|
|
# Cleanup
|
2010-02-15 11:23:34 +01:00
|
|
|
#
|
|
|
|
|
# Test for bug #51134 "Crash in MDL_lock::destroy on a concurrent
|
|
|
|
|
# DDL workload".
|
|
|
|
|
#
|
|
|
|
|
drop tables if exists t1, t2, t3;
|
|
|
|
|
create table t3 (i int);
|
|
|
|
|
# Switching to connection 'con1'
|
|
|
|
|
# Lock 't3' so upcoming RENAME is blocked.
|
|
|
|
|
lock table t3 read;
|
|
|
|
|
# Switching to connection 'con2'
|
|
|
|
|
# Remember ID for this connection.
|
|
|
|
|
# Start statement which will try to acquire two instances
|
|
|
|
|
# of X metadata lock on the same object.
|
|
|
|
|
# Sending:
|
|
|
|
|
rename tables t1 to t2, t2 to t3;;
|
|
|
|
|
# Switching to connection 'default'
|
|
|
|
|
# Wait until RENAME TABLE is blocked on table 't3'.
|
|
|
|
|
# Kill RENAME TABLE.
|
|
|
|
|
kill query ID;
|
|
|
|
|
# Switching to connection 'con2'
|
|
|
|
|
# RENAME TABLE should be aborted but should not crash.
|
|
|
|
|
ERROR 70100: Query execution was interrupted
|
|
|
|
|
# Switching to connection 'con1'
|
|
|
|
|
unlock tables;
|
|
|
|
|
# Switching to connection 'default'
|
|
|
|
|
drop table t3;
|
2010-02-26 13:40:25 +01:00
|
|
|
#
|
|
|
|
|
# Test for the bug where upgradable metadata locks was acquired
|
|
|
|
|
# even if the table to altered was temporary.
|
|
|
|
|
# Bug found while working on the related bug #51240.
|
|
|
|
|
#
|
|
|
|
|
DROP TABLE IF EXISTS t1;
|
|
|
|
|
CREATE TABLE t1 (id INT);
|
|
|
|
|
LOCK TABLE t1 WRITE;
|
|
|
|
|
# Connection con1
|
|
|
|
|
CREATE TEMPORARY TABLE t1 (id INT);
|
|
|
|
|
ALTER TABLE t1 ADD COLUMN j INT;
|
|
|
|
|
# Connection default
|
|
|
|
|
UNLOCK TABLES;
|
|
|
|
|
DROP TABLE t1;
|