Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2(EOL)
Description
Note: I can't say whether the problem is new, because until recently the test case failed with MDEV-17432 (and it still does on 10.3+).
Run the test case with --repeat=N. It usually fails for me on the 2nd attempt. Possibly when the reason is known, it can be converted into a deterministic test case. It would also be good to get rid of the long lock_wait_timeout.
--source include/have_innodb.inc
|
|
|
CREATE TABLE t1 ( |
pk INT AUTO_INCREMENT, |
c CHAR(105) NOT NULL DEFAULT '', |
PRIMARY KEY(pk), |
FULLTEXT KEY(c) |
) ENGINE=InnoDB;
|
|
|
--error ER_CANT_CREATE_TABLE
|
ALTER TABLE t1 ADD FOREIGN KEY (c) REFERENCES x(x); |
LOCK TABLE t1 READ; |
|
|
--connect (con1,localhost,root,,test)
|
|
|
SET lock_wait_timeout= 10; |
--error ER_LOCK_WAIT_TIMEOUT
|
FLUSH TABLES;
|
|
|
# Cleanup
|
--disconnect con1
|
--connection default
|
UNLOCK TABLES;
|
DROP TABLE t1; |
|
10.2 5ec9b88e1 |
#3 <signal handler called>
|
#4 0x000055bb3f86e67b in fts_is_sync_needed (tables=0x55bb424f0508) at /data/src/10.2-bug/storage/innobase/fts/fts0opt.cc:2805
|
#5 0x000055bb3f86e9cc in fts_optimize_thread (arg=0x55bb424f02a0) at /data/src/10.2-bug/storage/innobase/fts/fts0opt.cc:2901
|
#6 0x00007f7d723be494 in start_thread (arg=0x7f7d577fe700) at pthread_create.c:333
|
#7 0x00007f7d709bf93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|