[MDEV-6525] Assertion `table->pos_in_locked _tables == __null || table->pos_in_locked_tables->table = table' failed in mark_used_tables_as_free_for_reuse, locking problems and binlogging problems on CREATE OR REPLACE under lock Created: 2014-08-04  Updated: 2014-09-12  Resolved: 2014-09-12

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.12
Fix Version/s: 10.0.14

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Attachments: File mdev6525.tar.gz    

 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



 Comments   
Comment by Elena Stepanova [ 2014-08-04 ]

Error and general logs are attached as mdev6525.tar.gz

Comment by Elena Stepanova [ 2014-08-08 ]

Also observed on a regular x86_64 machine, so it's not PPC64-specific.

Comment by Michael Widenius [ 2014-09-08 ]

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.

Comment by Michael Widenius [ 2014-09-12 ]

Fix pushed

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