Sergei Golubchik added a comment - 2021-04-26 11:52 ramesh , is it a bug? may be it's supposed to crash. Please, clarify.

Ramesh Sivaraman added a comment - 2021-04-26 13:45 serg I think it is a bug as the crash is only happening when we execute DROP TABLE immediately after ALTER TABLE statement. When we add 1 sec delay after ALTER TABLE statement the crash is not happening. innodb.drop_table_background MTR test also crashing if we add ALTER TABLE statement in the testcase. $ grep -A6 add suite/innodb/t/drop_table_background.test SET DEBUG_DBUG='+d,row_drop_table_add_to_background'; CREATE TABLE t1 (a INT NOT NULL) ENGINE=InnoDB; ALTER TABLE t1 ADD c2 TEXT NOT NULL; DROP TABLE t1;   --disable_query_log Executed DROP TABLE statement after ALTER TABLE statement without any delay. 10.2.38-dbg>SET debug_dbug='+d,row_drop_table_add_to_background'; Query OK, 0 rows affected (0.00 sec)   10.2.38-dbg>CREATE TABLE t1 (a INT NOT NULL) ENGINE=InnoDB; Query OK, 0 rows affected (0.02 sec)   10.2.38-dbg>ALTER TABLE t1 ADD c2 TEXT NOT NULL; Query OK, 0 rows affected (0.03 sec) Records: 0 Duplicates: 0 Warnings: 0   10.2.38-dbg>DROP TABLE t1;   ERROR 2013 (HY000): Lost connection to MySQL server during query 10.2.38-dbg>   General Log:   210426 16:30:58 9 Query SET debug_dbug='+d,row_drop_table_add_to_background' 9 Query CREATE TABLE t1 (a INT NOT NULL) ENGINE=InnoDB 9 Query ALTER TABLE t1 ADD c2 TEXT NOT NULL 9 Query DROP TABLE t1 Executed DROP TABLE statement after ALTER TABLE statement with 1sec delay. 10.2.38-dbg>SET debug_dbug='+d,row_drop_table_add_to_background'; Query OK, 0 rows affected (0.00 sec)   10.2.38-dbg>CREATE TABLE t1 (a INT NOT NULL) ENGINE=InnoDB; Query OK, 0 rows affected (0.02 sec)   10.2.38-dbg>ALTER TABLE t1 ADD c2 TEXT NOT NULL; Query OK, 0 rows affected (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0   10.2.38-dbg>SELECT SLEEP(1);   +----------+ | SLEEP(1) | +----------+ | 0 | +----------+ 1 row in set (1.00 sec)   10.2.38-dbg>DROP TABLE t1; Query OK, 0 rows affected (0.01 sec)   10.2.38-dbg>   General Log:   210426 16:32:02 9 Query SET debug_dbug='+d,row_drop_table_add_to_background' 9 Query CREATE TABLE t1 (a INT NOT NULL) ENGINE=InnoDB 9 Query ALTER TABLE t1 ADD c2 TEXT NOT NULL 9 Query SELECT SLEEP(1) 210426 16:32:03 9 Query DROP TABLE t1

Roel Van de Paar added a comment - 2021-04-26 22:15 The issue is also only present in 10.2 so something changed in 10.3 and onwards.

Sergei Golubchik added a comment - 2021-04-28 11:42 What does this row_drop_table_add_to_background do? Could a crash be an expected effect of it?

Marko Mäkelä added a comment - 2021-04-29 10:03 I can repeat the crash on 10.6 with a more generic test case that does not depend on MDEV-11369 : --source include/have_innodb.inc SET debug_dbug= '+d,row_drop_table_add_to_background' ; CREATE TABLE t1 (a INT NOT NULL ) ENGINE=InnoDB; ALTER TABLE t1 FORCE ; DROP TABLE t1; The duplicate table name was created in ctx->tmp_name by dict_mem_create_temporary_tablename() in ha_innobase::commit_inplace_alter_table() for discarding the old copy of t1 . We used the wrong table identifier when constructing the name. The purpose of that identifier is to ultimately discard the old copy of the table. The following patch makes the test case pass: diff --git a/storage/innobase/handler/handler0alter.cc b/storage/innobase/handler/handler0alter.cc index 3ac4f4fe4c1..1a58ca7ea36 100644 --- a/storage/innobase/handler/handler0alter.cc +++ b/storage/innobase/handler/handler0alter.cc @@ -8520,7 +8520,7 @@ ha_innobase::commit_inplace_alter_table( } else if (ctx->need_rebuild()) { ctx->tmp_name = dict_mem_create_temporary_tablename( ctx->heap, ctx->new_table->name.m_name, - ctx->new_table->id); + ctx->old_table->id); fail = commit_try_rebuild( ha_alter_info, ctx, altered_table, table,

Marko Mäkelä added a comment - 2021-04-29 10:26 My code change would cause a failure of an existing regression test: CURRENT_TEST: innodb.rename_table_debug mysqltest: At line 38: query 'SELECT * FROM t1' failed: 1286: Unknown storage engine 'InnoDB' The server error log contains the following: 2021-04-29 13:09:08 140098167039936 [Note] InnoDB: Starting crash recovery from checkpoint LSN=3701637 2021-04-29 13:09:08 140098167039936 [Note] InnoDB: Ignoring data file './test/t2.ibd' with space ID 69. Another data file called ./test/t1.ibd exists with the same space ID. 2021-04-29 13:09:08 140098167039936 [ERROR] InnoDB: Cannot rename './test/t1.ibd' to './test/t2.ibd' for space ID 69 because the target file exists. Remove the target file and try again. 2021-04-29 13:09:08 140098167039936 [ERROR] InnoDB: Cannot replay file rename. Remove either file and try again. 2021-04-29 13:09:08 140098167039936 [ERROR] InnoDB: Plugin initialization aborted at srv0start.cc[2209] with error Generic error 2021-04-29 13:09:09 140098167039936 [Note] InnoDB: Starting shutdown... The background DROP TABLE queue would be removed in MDEV-21175 . Until then, I think that failures like this are possible (but unlikely) even without setting the debug parameter. A more complex scenario would involve a FOREIGN KEY check that is being performed on the table near the time the ALTER TABLE is finishing. In that case, the old copy of the table would be renamed, to be added to the background DROP TABLE queue. If a DROP TABLE is being executed on the newly rebuilt table such that also for that table, another FOREIGN KEY check is in progress, and the queue had not been emptied yet, then we would have a duplicate name for the table.

Marko Mäkelä added a comment - 2021-05-17 11:33 For the originally reported failure, a possible solution could be to allocate a different type of a temporary table name in ha_innobase::commit_inplace_alter_table() . That name could consist of both the current table ID as well as the related table ID. In that way, a clash between the two to-be-dropped table names would not be possible.

Marko Mäkelä added a comment - 2022-11-08 17:00 This was fixed in MDEV-25506 in MariaDB Server 10.6.2. I do not think that it is feasible to fix this in older releases.