[MDEV-21550] Assertion `!table->fts->in_queue' failed in fts_optimize_remove_table Created: 2020-01-21  Updated: 2020-01-31  Resolved: 2020-01-28

Status: Closed
Project: MariaDB Server
Component/s: Full-text Search, Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.2.32, 10.3.23, 10.4.13

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Thirunarayanan Balathandayuthapani
Resolution: Fixed Votes: 0
Labels: None

Attachments: File 10.2-MDEV-21550v1.patch     File mdev-21550-10.2v1.patch    

 Description   

--source include/have_sequence.inc
--source include/have_innodb.inc
 
CREATE TABLE t1 (pk INT, a VARCHAR(8), PRIMARY KEY(pk)) ENGINE=InnoDB;
CREATE TABLE t2 (b INT, FOREIGN KEY(b) REFERENCES t1(pk)) ENGINE=InnoDB;
 
INSERT INTO t1 SELECT seq, CONCAT('foo',seq) FROM seq_1_to_1000;
ALTER TABLE t1 ADD FULLTEXT KEY fk1(a);
ALTER TABLE t1 ADD FULLTEXT KEY fk2(a);
--error ER_ROW_IS_REFERENCED_2
CREATE OR REPLACE TABLE t1 (f INT);
REPLACE INTO t1 SELECT seq, CONCAT('foo',seq) FROM seq_1_to_1000;
ALTER TABLE t1 FORCE;
 
# Cleanup
DROP TABLE t2, t1;

10.4 25918576 debug

mysqld: /data/src/10.4/storage/innobase/fts/fts0opt.cc:2620: void fts_optimize_remove_table(dict_table_t*): Assertion `!table->fts->in_queue' failed.
200121 19:34:10 [ERROR] mysqld got signal 6 ;
 
#7  0x00007ff3dc139f12 in __GI___assert_fail (assertion=0x5570869f845c "!table->fts->in_queue", file=0x5570869f7940 "/data/src/10.4/storage/innobase/fts/fts0opt.cc", line=2620, function=0x5570869f9020 <fts_optimize_remove_table(dict_table_t*)::__PRETTY_FUNCTION__> "void fts_optimize_remove_table(dict_table_t*)") at assert.c:101
#8  0x000055708635af2d in fts_optimize_remove_table (table=0x7ff38c1a4b68) at /data/src/10.4/storage/innobase/fts/fts0opt.cc:2620
#9  0x0000557086104707 in row_drop_table_for_mysql (name=0x7ff3d5504920 "test/#sql2-5fe2-9", trx=0x7ff3d5fa4268, sqlcom=SQLCOM_ALTER_TABLE, create_failed=false, nonatomic=true) at /data/src/10.4/storage/innobase/row/row0mysql.cc:3399
#10 0x0000557085f7b839 in ha_innobase::delete_table (this=0x7ff38c015cb0, name=0x7ff3d55063f0 "./test/#sql2-5fe2-9", sqlcom=SQLCOM_ALTER_TABLE) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:13173
#11 0x0000557085f64d62 in ha_innobase::delete_table (this=0x7ff38c015cb0, name=0x7ff3d55063f0 "./test/#sql2-5fe2-9") at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:13298
#12 0x0000557085d1733e in handler::ha_delete_table (this=0x7ff38c015cb0, name=0x7ff3d55063f0 "./test/#sql2-5fe2-9") at /data/src/10.4/sql/handler.cc:4695
#13 0x0000557085d1035d in ha_delete_table (thd=0x7ff38c000af0, table_type=0x557088fc71a0, path=0x7ff3d55063f0 "./test/#sql2-5fe2-9", db=0x7ff3d5508110, alias=0x7ff3d5506800, generate_warning=false) at /data/src/10.4/sql/handler.cc:2588
#14 0x0000557085a8a262 in quick_rm_table (thd=0x7ff38c000af0, base=0x557088fc71a0, db=0x7ff3d5508110, table_name=0x7ff3d5506800, flags=3, table_path=0x0) at /data/src/10.4/sql/sql_table.cc:2767
#15 0x0000557085a9ff8d in mysql_alter_table (thd=0x7ff38c000af0, new_db=0x7ff38c0052b0, new_name=0x7ff38c0056b8, create_info=0x7ff3d5508cf0, table_list=0x7ff38c013270, alter_info=0x7ff3d5508c30, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10385
#16 0x0000557085b37441 in Sql_cmd_alter_table::execute (this=0x7ff38c013938, thd=0x7ff38c000af0) at /data/src/10.4/sql/sql_alter.cc:508
#17 0x00005570859b5e0d in mysql_execute_command (thd=0x7ff38c000af0) at /data/src/10.4/sql/sql_parse.cc:6102
#18 0x00005570859bb4cf in mysql_parse (thd=0x7ff38c000af0, rawbuf=0x7ff38c013198 "ALTER TABLE t1 FORCE", length=20, parser_state=0x7ff3d550a160, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7901
#19 0x00005570859a669c in dispatch_command (command=COM_QUERY, thd=0x7ff38c000af0, packet=0x7ff38c1376f1 "", packet_length=20, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
#20 0x00005570859a4d29 in do_command (thd=0x7ff38c000af0) at /data/src/10.4/sql/sql_parse.cc:1360
#21 0x0000557085b2dd51 in do_handle_one_connection (connect=0x557089305170) at /data/src/10.4/sql/sql_connect.cc:1412
#22 0x0000557085b2daa0 in handle_one_connection (arg=0x557089305170) at /data/src/10.4/sql/sql_connect.cc:1316
#23 0x00005570865354b7 in pfs_spawn_thread (arg=0x55708930d280) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#24 0x00007ff3de0c24a4 in start_thread (arg=0x7ff3d550b700) at pthread_create.c:456
#25 0x00007ff3dc1f6d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible with 10.2-10.5.
No obvious effect on a non-debug build.
10.1 doesn't crash, it behaves weirdly in a different way: CREATE OR REPLACE passes without a complain, but the table doesn't get re-created.



 Comments   
Comment by Thirunarayanan Balathandayuthapani [ 2020-01-27 ]

The attached patch solves the issue. It adds the FTS table back to the queue when drop table fails.
10.2-MDEV-21550v1.patch

Comment by Thirunarayanan Balathandayuthapani [ 2020-01-28 ]

mdev-21550-10.2v1.patch

The problem is that InnoDB doesn't add the table in fts slots if drop table fails. InnoDB marks the table is in fts slots while processing sync message.
So the consecutive alter statement assumes that table is in queue and tries to remove it. But InnoDB can't find the table in fts_slots. It is caused by MDEV-20621.
Attaching the patch which does removal of setting the flag during fts_sync_request_to_table() and adds the FTS table back to fts_slots when drop table fails.

Comment by Marko Mäkelä [ 2020-01-28 ]

OK to push. Please simplify the test case even more to merge the first ALTER to the CREATE TABLE statement.

Generated at Thu Feb 08 09:07:59 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.