| 2014-08-26 09:46:35 |
Laurynas Biveinis |
description |
For example, http://jenkins.percona.com/job/percona-server-5.6-trunk/310/
has 8 failure instances. They look as follows
mysqltest: At line 50: query 'drop table t2,t3' failed: 1213: Deadlock found when trying to get lock; try restarting transaction
The relevant test snippet is
connection master;
...
send update t2 set a = a + 1 + get_lock('crash_lock%20C', 10);
connection master1;
...
kill @id;
drop table t2,t3;
...
connection master;
# The get_lock function causes warning for unsafe statement.
--disable_warnings
--error 0,1317,2013
reap;
It looks like this is caused by the async KILL completing, and DROP TABLE processing MDL locks before the UPDATE thread checking its kill flag and releasing the locks. The easiest fix seems to be moving DROP TABLE to the master connection to be executed after reap. |
For example, http://jenkins.percona.com/job/percona-server-5.6-trunk/310/
has 8 failure instances. They look as follows
mysqltest: At line 50: query 'drop table t2,t3' failed: 1213: Deadlock found when trying to get lock; try restarting transaction
The relevant test snippet is
connection master1;
select get_lock('crash_lock%20C', 10);
connection master;
...
send update t2 set a = a + 1 + get_lock('crash_lock%20C', 10);
connection master1;
...
kill @id;
drop table t2,t3;
...
connection master;
# The get_lock function causes warning for unsafe statement.
--disable_warnings
--error 0,1317,2013
reap;
It looks like this is caused by the async KILL completing, and DROP TABLE processing MDL locks before the UPDATE thread checking its kill flag and releasing the locks. The easiest fix seems to be moving DROP TABLE to the master connection to be executed after reap. |
|
