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
|
2009-12-03 23:08:27 +03:00
|
|
|
where state = "Table 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
|
2009-12-03 23:08:27 +03:00
|
|
|
where state = "Table 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
|
2009-12-03 23:08:27 +03:00
|
|
|
where state = "Table 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
|
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
|
|
|
where state = "Waiting for table" 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
|
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
|
|
|
where state = "Waiting for table" 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
|
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
|
|
|
WHERE state = "Waiting for table" 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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table" 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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table" 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
|
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
|
|
|
where state = "Waiting for table" 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
|
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
|
|
|
where state = "Waiting for table" 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
|
|
|
|
|
where state = "Waiting for table" and info = "flush tables with read lock";
|
|
|
|
|
--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
|
2009-12-03 23:08:27 +03:00
|
|
|
where state = "Table 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
|
2009-12-03 23:08:27 +03:00
|
|
|
where state = "Table lock" and info = "select * from t1";
|
2007-08-05 13:55:37 +04:00
|
|
|
--source include/wait_condition.inc
|
2009-12-03 23:08:27 +03:00
|
|
|
let $ID= `select id from information_schema.processlist where state = "Table 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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table";
|
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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table";
|
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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table";
|
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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table";
|
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
|
2009-12-03 23:08:27 +03:00
|
|
|
where state = "Table 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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table";
|
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
|
2009-11-30 18:55:03 +03:00
|
|
|
where state = "Waiting for table";
|
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
|
|
|
|
|
where state = "Waiting for table" and info = "alter table t1 add column c4 int";
|
|
|
|
|
--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;
|
|
|
|
|
|
|
|
|
|
|
2009-03-03 21:34:18 +01:00
|
|
|
# Wait till all disconnects are completed
|
|
|
|
|
--source include/wait_until_count_sessions.inc
|