Intermittent rpl_err_ignoredtable failures on the 5.6 trunk
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
|||
Percona Server moved to https://jira.percona.com/projects/PS |
Fix Released
|
Low
|
Laurynas Biveinis | ||
5.1 |
Invalid
|
Undecided
|
Unassigned | ||
5.5 |
Invalid
|
Undecided
|
Unassigned | ||
5.6 |
Fix Released
|
Low
|
Laurynas Biveinis |
Bug Description
For example, http://
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(
connection master;
...
send update t2 set a = a + 1 + get_lock(
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.
Related branches
- Laurynas Biveinis (community): Approve
-
Diff: 13 lines (+3/-0)1 file modifiedmysql-test/suite/rpl/t/rpl_err_ignoredtable.test (+3/-0)
tags: | added: ci upstream |
description: | updated |
5.1 and 5.5 testcase looks the same, but not opening the bug, because I was unable to find recent occurrences of the failure there. (Not sure how would pre-MDL 5.1 failure look like neither).