Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Cannot Reproduce
-
11.0(EOL)
-
None
Description
In the test case below, one connection performs ALTER, while another has something to do with statistical tables. Every ones in a while, ALTER fails with a timeout. Apparently the timeout concerns statistical tables, as there seems to be no other relation between connections. Even though the ALTER fails, the modification it performed remains, e.g. in this case the column remains renamed.
The practical effect is, for example, further replication discrepancy: since ALTER fails, it is not written in the binlog, so table remains unchanged on the slave, which causes further discrepancies.
Notes:
- the test case is very non-deterministic, run with big enough --repeat=N. Do not put it into the regression suite, create a deterministic one instead! It usually fails for me within ~20 attempts, but it can vary a lot on different machines and builds;
- sequences and prepared statement are not important, they are just used to create tables with many columns;
- tables can be (at least) MyISAM, Aria, or InnoDB, although it seems to take a bit longer with MyISAM;
- could not reproduce on the baseline.
--source include/have_sequence.inc
|
|
|
select concat('create table t1 (',group_concat(concat('c',seq,' int')),')') into @create_tbl from seq_1_to_300; |
execute immediate @create_tbl; |
create table t2 like t1; |
|
|
--connect (con1,localhost,root,,)
|
--send
|
analyze table t1 persistent for all; |
|
|
--connection default
|
--error 0,ER_LOCK_WAIT_TIMEOUT
|
alter table t2 nowait rename column c298 TO c298_renamed; |
if ($mysql_errno) |
{
|
show create table t2; |
--die ALTER failed with ER_LOCK_WAIT_TIMEOUT, check whether `c298` column is still there |
}
|
|
|
drop table t1, t2; |
|
bb-11.0-oalter e599b8b4586 |
show create table t2; |
Table Create Table |
t2 CREATE TABLE `t2` ( |
`c1` int(11) DEFAULT NULL, |
`c2` int(11) DEFAULT NULL, |
...
|
`c298_renamed` int(11) DEFAULT NULL, |
`c299` int(11) DEFAULT NULL, |
`c300` int(11) DEFAULT NULL |
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci |
|
|
mysqltest: At line 17: ALTER failed with ER_LOCK_WAIT_TIMEOUT, check whether `c298` column is still there |
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
This bug wasn't related to innodb's inplace, but to a generic inplace (as it shows up, myisam and maria can also do renaming), and, as predicted by marko, is related to "engine independent table statistics".
The lock timeout is reported, because the stat table is opened by ANALYZE TABLE, and a table was still ALTERed, because the proper error handling was missing in the alter table code.
serg can we just ignore the error from rename_column_in_stat_tables?
I see that thd->clear_error() was there until commit 313855766f3c
Note: the fix with a proper handing (bailout) is here
(it can be thd->clear_error() instead)
the deterministic test:
create table t1 (c1 int, c2 int, c3 int); |
create table t2 like t1; |
|
|
--connect (con1,localhost,root,,)
|
set debug_sync= "statistics_update_table_opened SIGNAL open WAIT_FOR done"; |
--send
|
analyze table t1 persistent for all; |
|
|
--connection default
|
set debug_sync= "now WAIT_FOR open"; |
--error ER_LOCK_WAIT_TIMEOUT
|
alter table t2 nowait rename column c3 TO c3_renamed; |
show warnings;
|
|
|
show create table t2; |
|
|
set debug_sync= "now SIGNAL done"; |
|
|
drop table t1, t2; |
Actually, in the end I too reproduced this on a 11.1 based branch once, but without rr record.