Elena Stepanova added a comment - 2015-05-21 20:43 On a debug server the same test case causes an assertion failure. Here is a simpified/obfuscated test which causes the same failure: CREATE TABLE t1 (f1 INT ) ENGINE=Aria; INSERT INTO t1 VALUES (1);   CREATE TABLE t2 (f2 INT ) ENGINE=MyISAM; CREATE TABLE tmp (f3 INT ) engine=Aria; LOCK TABLE t2 WRITE, tmp WRITE, tmp AS tmp_alias WRITE, t1 WRITE;   INSERT INTO tmp SELECT f1 FROM t1; INSERT INTO t2 SELECT f3 FROM tmp AS tmp_alias; Stack trace from 5.5 commit 0014bdc7eef 5.5/sql/sql_select.cc:17352: int join_read_const_table(JOIN_TAB*, POSITION*): Assertion `table->file->stats.records > 0 || error' failed. 150521 20:38:56 [ERROR] mysqld got signal 6 ;   #6 0x00007ff6b1a16311 in *__GI___assert_fail (assertion=0xd6d1b8 "table->file->stats.records > 0 || error", file=<optimized out>, line=17352, function=0xd6eba0 "int join_read_const_table(JOIN_TAB*, POSITION*)") at assert.c:81 #7 0x000000000068e91c in join_read_const_table (tab=0x7ff6ac688530, pos=0x7ff6ac688a60) at 5.5/sql/sql_select.cc:17352 #8 0x000000000066d701 in make_join_statistics (join=0x7ff6ac687f70, tables_list=..., conds=0x0, keyuse_array=0x7ff6ac688270) at 5.5/sql/sql_select.cc:3408 #9 0x0000000000665e7c in JOIN::optimize (this=0x7ff6ac687f70) at 5.5/sql/sql_select.cc:1227 #10 0x000000000066c6e5 in mysql_select (thd=0x7ff6ad550060, rref_pointer_array=0x7ff6ad553cd0, tables=0x7ff6ac6878c0, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3492023040, result=0x7ff6ac687ed8, unit=0x7ff6ad553380, select_lex=0x7ff6ad553a60) at 5.5/sql/sql_select.cc:3078 #11 0x0000000000663261 in handle_select (thd=0x7ff6ad550060, lex=0x7ff6ad5532d0, result=0x7ff6ac687ed8, setup_tables_done_option=1073741824) at 5.5/sql/sql_select.cc:319 #12 0x0000000000637655 in mysql_execute_command (thd=0x7ff6ad550060) at 5.5/sql/sql_parse.cc:3060 #13 0x000000000063ef86 in mysql_parse (thd=0x7ff6ad550060, rawbuf=0x7ff6ac687078 "INSERT INTO t2 SELECT f3 FROM tmp AS tmp_alias", length=46, parser_state=0x7ff6acfb5620) at 5.5/sql/sql_parse.cc:5909 #14 0x0000000000632bc9 in dispatch_command (command=COM_QUERY, thd=0x7ff6ad550060, packet=0x7ff6ad607061 "INSERT INTO t2 SELECT f3 FROM tmp AS tmp_alias", packet_length=46) at 5.5/sql/sql_parse.cc:1079 #15 0x0000000000631d55 in do_command (thd=0x7ff6ad550060) at 5.5/sql/sql_parse.cc:793 #16 0x0000000000734b0a in do_handle_one_connection (thd_arg=0x7ff6ad550060) at 5.5/sql/sql_connect.cc:1266 #17 0x00000000007345c9 in handle_one_connection (arg=0x7ff6ad550060) at 5.5/sql/sql_connect.cc:1181 #18 0x0000000000b6d45d in pfs_spawn_thread (arg=0x7ff6ad571ca0) at 5.5/storage/perfschema/pfs.cc:1015 #19 0x00007ff6b3810b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #20 0x00007ff6b1ac695d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 After fixing, please also check the initial test case (ftp.askmonty.org/private/mdev-8200.sql), see a comment about the expected result at the end of the file.

roberto spadim added a comment - 2015-05-27 00:22 i didn't confirmed yet, but i think it's happening with temporary tables using aria too, i changed all production servers to use myisam

Michael Widenius added a comment - 2018-01-10 23:20 This bug should only happens when locking the same Aria "transactional" table (page format) more then once with LOCK TABLES and inserting into one of them with INSERT ... SELECT when the table is empty. I am now running tests and will push when all test has passed.

Michael Widenius added a comment - 2018-01-11 14:42 Fix pushed into 5.5