[MDEV-18441] Assertion `tables_opened == 1' failed in mysql_alter_table upon adding FK to a MERGE table Created: 2019-01-31  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - MyISAM
Affects Version/s: 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Oleksandr Byelkin
Resolution: Unresolved Votes: 0
Labels: None


 Description   

CREATE TABLE t1 (a INT, b INT, PRIMARY KEY (a)) ENGINE=MyISAM;
CREATE TABLE t2 (a INT, b INT, PRIMARY KEY (a)) ENGINE=MERGE UNION=(t1);
ALTER TABLE t2 ADD FOREIGN KEY (a) REFERENCES t2 (b), ALGORITHM=COPY;
 
# Cleanup
DROP TABLE t2, t1;

10.1 6e2af7d0

mysqld: /data/src/10.1/sql/sql_table.cc:9185: bool mysql_alter_table(THD*, char*, char*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, uint, ORDER*, bool): Assertion `tables_opened == 1' failed.
190201  0:38:51 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f6740b5fee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000055e53a404cc0 in mysql_alter_table (thd=0x7f6720000b00, new_db=0x7f67200051c0, new_name=0x7f6720005590, create_info=0x7f6736cceec0, table_list=0x7f67200152b0, alter_info=0x7f6736ccee00, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:9790
#9  0x000055e53a48fcc8 in Sql_cmd_alter_table::execute (this=0x7f6720015b00, thd=0x7f6720000b00) at /data/src/10.4/sql/sql_alter.cc:499
#10 0x000055e53a32b51e in mysql_execute_command (thd=0x7f6720000b00) at /data/src/10.4/sql/sql_parse.cc:6306
#11 0x000055e53a330658 in mysql_parse (thd=0x7f6720000b00, rawbuf=0x7f6720015178 "ALTER TABLE t2 ADD FOREIGN KEY (a) REFERENCES t2 (b), ALGORITHM=COPY", length=68, parser_state=0x7f6736cd01f0, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8117
#12 0x000055e53a31beba in dispatch_command (command=COM_QUERY, thd=0x7f6720000b00, packet=0x7f672000a451 "ALTER TABLE t2 ADD FOREIGN KEY (a) REFERENCES t2 (b), ALGORITHM=COPY", packet_length=68, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1803
#13 0x000055e53a31a812 in do_command (thd=0x7f6720000b00) at /data/src/10.4/sql/sql_parse.cc:1356
#14 0x000055e53a489bdd in do_handle_one_connection (connect=0x55e53e6dd8a0) at /data/src/10.4/sql/sql_connect.cc:1398
#15 0x000055e53a48994e in handle_one_connection (arg=0x55e53e6dd8a0) at /data/src/10.4/sql/sql_connect.cc:1301
#16 0x000055e53a97285d in pfs_spawn_thread (arg=0x55e53e6f56f0) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#17 0x00007f6742836494 in start_thread (arg=0x7f6736cd1700) at pthread_create.c:333
#18 0x00007f6740c1c93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

No visible effect on a non-debug build.



 Comments   
Comment by Elena Stepanova [ 2019-05-06 ]

Just for the record, on a build with -DCMAKE_C_FLAGS=-DDBUG_ASSERT_AS_PRINTF -DCMAKE_CXX_FLAGS=-DDBUG_ASSERT_AS_PRINTF -DCMAKE_BUILD_TYPE=RelWithDebInfo the same test case produces the second printed assertion after the first one:

Warning: assertion failed: tables_opened == 1 at /data/src/10.4/sql/sql_table.cc line 10069
Attempting backtrace to find out the reason for the assert:
stack_bottom = 0x0 thread_stack 0x49000
/data/bld/10.4-rel-with-asserts/bin/mysqld(my_print_stacktrace+0x29)[0x5578c38ebbe9]
mysys/stacktrace.c:270(my_print_stacktrace)[0x5578c325dc4e]
sql/sql_table.cc:10070(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool))[0x5578c32b5301]
sql/sql_alter.cc:496(Sql_cmd_alter_table::execute(THD*))[0x5578c31c7a52]
sql/sql_parse.cc:6340(mysql_execute_command(THD*))[0x5578c31d0348]
sql/sql_parse.cc:8167(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x5578c31d2c78]
sql/sql_parse.cc:1893(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x5578c31d4022]
sql/sql_parse.cc:1363(do_command(THD*))[0x5578c32b0794]
sql/sql_connect.cc:1398(do_handle_one_connection(CONNECT*))[0x5578c32b08b4]
sql/sql_connect.cc:1303(handle_one_connection)[0x5578c38a5f64]
nptl/pthread_create.c:456(start_thread)[0x7fda38a164a4]
x86_64/clone.S:99(clone)[0x7fda36f5ed0f]

Warning: assertion failed: &table_list->next_global == thd->lex->query_tables_last at /data/src/10.4/sql/sql_table.cc line 10070
Attempting backtrace to find out the reason for the assert:
stack_bottom = 0x0 thread_stack 0x49000
mysys/stacktrace.c:270(my_print_stacktrace)[0x5578c38ebbe9]
sql/sql_table.cc:10072(mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool))[0x5578c325dc7f]
sql/sql_alter.cc:496(Sql_cmd_alter_table::execute(THD*))[0x5578c32b5301]
sql/sql_parse.cc:6340(mysql_execute_command(THD*))[0x5578c31c7a52]
sql/sql_parse.cc:8167(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x5578c31d0348]
sql/sql_parse.cc:1893(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x5578c31d2c78]
sql/sql_parse.cc:1363(do_command(THD*))[0x5578c31d4022]
sql/sql_connect.cc:1398(do_handle_one_connection(CONNECT*))[0x5578c32b0794]
sql/sql_connect.cc:1303(handle_one_connection)[0x5578c32b08b4]
perfschema/pfs.cc:1865(pfs_spawn_thread)[0x5578c38a5f64]
nptl/pthread_create.c:456(start_thread)[0x7fda38a164a4]
x86_64/clone.S:99(clone)[0x7fda36f5ed0f]

It's probably just the "garbage in, garbage out" situation, but might be useful for JIRA searching.

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