Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.12
-
Fix Version/s: 10.0.14
-
Component/s: None
-
Labels:None
Description
--source include/have_innodb.inc --source include/have_binlog_format_statement.inc --source include/have_metadata_lock_info.inc --enable_connect_log CREATE TABLE t1 (a INT) ENGINE=InnoDB; CREATE FUNCTION f1() RETURNS INT RETURN ( SELECT MAX(a) FROM t1 ); --connect (con1,localhost,root,,test) CREATE TEMPORARY TABLE tmp (b INT) ENGINE=InnoDB; LOCK TABLE t1 WRITE; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT * FROM information_schema.metadata_lock_info; CREATE OR REPLACE TABLE t1 LIKE tmp; SELECT * FROM information_schema.metadata_lock_info; SHOW CREATE TABLE t1; --connection default SELECT f1();
The test case above causes several problems. They might have the same root cause or be unrelated; in any case they all need to be addressed.
In order of appearance:
Binary logging complaints
CREATE OR REPLACE TABLE t1 LIKE tmp causes a bunch of warnings of type Error:
CREATE OR REPLACE TABLE t1 LIKE tmp;
Warnings:
Error 1665 Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.
Error 1015 Can't lock file (errno: 170 "It is not possible to log this statement")
Error 1213 Deadlock found when trying to get lock; try restarting transaction
It's unexpected – it should be pure DDL, why would we suddenly care about binlog format?
It seems to only be happening under LOCK.
Disappearance of locks
The CREATE OR REPLACE TABLE t1 LIKE tmp , despite the warnings, gets executed. However, all locks are gone after that – I don't think it is supposed to happen:
SELECT * FROM information_schema.metadata_lock_info; THREAD_ID LOCK_MODE LOCK_DURATION LOCK_TYPE TABLE_SCHEMA TABLE_NAME 5 MDL_INTENTION_EXCLUSIVE MDL_EXPLICIT Global read lock 5 MDL_SHARED_NO_READ_WRITE MDL_EXPLICIT Table metadata lock test t1 5 MDL_INTENTION_EXCLUSIVE MDL_EXPLICIT Schema metadata lock test CREATE OR REPLACE TABLE t1 LIKE tmp; Warnings: Error 1665 Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. Error 1015 Can't lock file (errno: 170 "It is not possible to log this statement") Error 1213 Deadlock found when trying to get lock; try restarting transaction SELECT * FROM information_schema.metadata_lock_info; THREAD_ID LOCK_MODE LOCK_DURATION LOCK_TYPE TABLE_SCHEMA TABLE_NAME
Assertion failure on the last SELECT f1():
10.0/sql/sql_base.cc:756: void mark_used_tables_as_free_for_reuse(THD*, TABLE*): Assertion `table->pos_in_locked_tables == __null || table->pos_in_locked_tables->table == table' failed. 140810 1:49:19 [ERROR] mysqld got signal 6 ;
#6 0x00007ff368f5b6f1 in *__GI___assert_fail (assertion=0xf1b9e0 "table->pos_in_locked_tables == __null || table->pos_in_locked_tables->table == table", file=<optimized out>, line=756, function=0xf1f0c0 "void mark_used_tables_as_free_for_reuse(THD*, TABLE*)") at assert.c:81 #7 0x0000000000615637 in mark_used_tables_as_free_for_reuse (thd=0x7ff35d61c070, table=0x7ff356111c70) at 10.0/sql/sql_base.cc:755 #8 0x0000000000615b75 in close_thread_tables (thd=0x7ff35d61c070) at 10.0/sql/sql_base.cc:953 #9 0x00000000009a56aa in sp_lex_keeper::reset_lex_and_exec_core (this=0x7ff355d57490, thd=0x7ff35d61c070, nextp=0x7ff36ae91a48, open_tables=true, instr=0x7ff355d57450) at 10.0/sql/sp_head.cc:2983 #10 0x00000000009a68a2 in sp_instr_freturn::execute (this=0x7ff355d57450, thd=0x7ff35d61c070, nextp=0x7ff36ae91a48) at 10.0/sql/sp_head.cc:3467 #11 0x00000000009a19c8 in sp_head::execute (this=0x7ff355dc2088, thd=0x7ff35d61c070, merge_da_on_success=true) at 10.0/sql/sp_head.cc:1366 #12 0x00000000009a2b36 in sp_head::execute_function (this=0x7ff355dc2088, thd=0x7ff35d61c070, argp=0xa5a5a5a5a5a5a5a5, argcount=0, return_value_fld=0x7ff355e90d50) at 10.0/sql/sp_head.cc:1906 #13 0x00000000008db057 in Item_func_sp::execute_impl (this=0x7ff355e8f330, thd=0x7ff35d61c070) at 10.0/sql/item_func.cc:6734 #14 0x00000000008dadf8 in Item_func_sp::execute (this=0x7ff355e8f330) at 10.0/sql/item_func.cc:6667 #15 0x00000000008ddddc in Item_func_sp::val_int (this=0x7ff355e8f330) at 10.0/sql/item_func.h:2069 #16 0x00000000008875ce in Item::send (this=0x7ff355e8f330, protocol=0x7ff35d61c5f8, buffer=0x7ff36ae92010) at 10.0/sql/item.cc:6641 #17 0x00000000005d1ddc in Protocol::send_result_set_row (this=0x7ff35d61c5f8, row_items=0x7ff35d620580) at 10.0/sql/protocol.cc:903 #18 0x000000000063ed29 in select_send::send_data (this=0x7ff355e90ce0, items=...) at 10.0/sql/sql_class.cc:2542 #19 0x00000000006b260a in JOIN::exec_inner (this=0x7ff355d3f088) at 10.0/sql/sql_select.cc:2455 #20 0x00000000006b202a in JOIN::exec (this=0x7ff355d3f088) at 10.0/sql/sql_select.cc:2369 #21 0x00000000006b53ad in mysql_select (thd=0x7ff35d61c070, rref_pointer_array=0x7ff35d6206e0, tables=0x0, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7ff355e90ce0, unit=0x7ff35d61fd80, select_lex=0x7ff35d620468) at 10.0/sql/sql_select.cc:3307 #22 0x00000000006ab98f in handle_select (thd=0x7ff35d61c070, lex=0x7ff35d61fcb8, result=0x7ff355e90ce0, setup_tables_done_option=0) at 10.0/sql/sql_select.cc:372 #23 0x0000000000680678 in execute_sqlcom_select (thd=0x7ff35d61c070, all_tables=0x0) at 10.0/sql/sql_parse.cc:5265 #24 0x0000000000678a17 in mysql_execute_command (thd=0x7ff35d61c070) at 10.0/sql/sql_parse.cc:2552 #25 0x0000000000682e03 in mysql_parse (thd=0x7ff35d61c070, rawbuf=0x7ff355e8f088 "SELECT f1()", length=11, parser_state=0x7ff36ae93610) at 10.0/sql/sql_parse.cc:6411 #26 0x0000000000675cb8 in dispatch_command (command=COM_QUERY, thd=0x7ff35d61c070, packet=0x7ff362a55071 "", packet_length=11) at 10.0/sql/sql_parse.cc:1307 #27 0x000000000067505d in do_command (thd=0x7ff35d61c070) at 10.0/sql/sql_parse.cc:1004 #28 0x0000000000791312 in do_handle_one_connection (thd_arg=0x7ff35d61c070) at 10.0/sql/sql_connect.cc:1379 #29 0x0000000000791065 in handle_one_connection (arg=0x7ff35d61c070) at 10.0/sql/sql_connect.cc:1293 #30 0x0000000000cc3992 in pfs_spawn_thread (arg=0x7ff35d6b7df0) at 10.0/storage/perfschema/pfs.cc:1860 #31 0x00007ff36ab14b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #32 0x00007ff36900c20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
Stack trace from:
revision-id: sergii@pisem.net-20140808155845-jiz321iz2o2bhn8e revno: 4346 branch-nick: 10.0
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Also observed on a regular x86_64 machine, so it's not PPC64-specific.
The bug was that innodb/xtradb thought that create or REPLACE was not safe to do in a transaction. This is not true as CREATE OR REPLACE will always be run in it's own transaction.
I fixed this by changing so that thd_sqlcom_can_generate_row_events() does not report that CREATE OR REPLACE is generating row events.
Fix pushed
Error and general logs are attached as mdev6525.tar.gz