[MDEV-14730] Assertion `m_lock_type == 2' failed in handler::ha_close Created: 2017-12-20  Updated: 2018-02-02  Resolved: 2017-12-21

Status: Closed
Project: MariaDB Server
Component/s: Partitioning, Versioned Tables
Affects Version/s: N/A
Fix Version/s: 10.3.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes MDEV-14932 Transaction not registered for MariaD... Closed

 Description   

Note: This is a non-deterministic test case, for reproducing only, don't put it into the regression suite. Run with --repeat=N (N == 5 was always enough on my machine, YMMV.

--source include/have_innodb.inc
--source include/have_partition.inc
 
SET @innodb_stats_persistent.save= @@innodb_stats_persistent;
SET GLOBAL innodb_stats_persistent= ON;
SET system_versioning_alter_history= KEEP;
 
CREATE OR REPLACE TABLE t1 (a INT) ENGINE=InnoDB WITH SYSTEM VERSIONING;
CREATE OR REPLACE TABLE t2 (b INT) ENGINE=InnoDB PARTITION BY HASH(b) PARTITIONS 2;
 
--connect (con1,localhost,root,,test)
SET innodb_lock_wait_timeout= 3;
--send
	ALTER TABLE t2 ORDER BY b;
 
--connection default
SET max_statement_time= 1;
ALTER TABLE t1 PARTITION BY system_time INTERVAL 1 HOUR (PARTITION p1 HISTORY, PARTITION pn CURRENT);
 
# Cleanup
--connection con1
--reap
--disconnect con1
--connection default
DROP TABLE t1, t2;
SET GLOBAL innodb_stats_persistent= @innodb_stats_persistent.save;

bb-10.3-temporal 6e530d4df548cd

2017-12-21  1:48:26 10 [ERROR] InnoDB: Cannot save table statistics for table `test`.`#sql-151a_a#P#p0` /* Partition `p0` */: Lock wait timeout
mysqld: /data/src/bb-10.3-temporal/sql/handler.cc:2612: int handler::ha_close(): Assertion `m_lock_type == 2' failed.
171221  1:48:26 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f1ad9b20ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000055f7f5608efc in handler::ha_close (this=0x7f1a7c03ca98) at /data/src/bb-10.3-temporal/sql/handler.cc:2612
#9  0x000055f7f5da3ab4 in ha_partition::close (this=0x7f1a7c03c228) at /data/src/bb-10.3-temporal/sql/ha_partition.cc:3817
#10 0x000055f7f5608f5c in handler::ha_close (this=0x7f1a7c03c228) at /data/src/bb-10.3-temporal/sql/handler.cc:2614
#11 0x000055f7f5435bc5 in open_table_from_share (thd=0x7f1a7c000b00, share=0x7f1a7c039560, alias=0x7f1acc6fe0b0 "#sql-151a_9", db_stat=1, prgflag=8, ha_open_flags=4114, outparam=0x7f1a7c03b5e0, is_create_table=false) at /data/src/bb-10.3-temporal/sql/table.cc:3535
#12 0x000055f7f55449ab in THD::open_temporary_table (this=0x7f1a7c000b00, share=0x7f1a7c039560, alias=0x7f1acc6fe0b0 "#sql-151a_9", open_in_engine=true) at /data/src/bb-10.3-temporal/sql/temporary_tables.cc:1112
#13 0x000055f7f55427cf in THD::create_and_open_tmp_table (this=0x7f1a7c000b00, hton=0x55f7f805edb0, frm=0x7f1acc6fd220, path=0x7f1acc6fe91c "./test/#sql-151a_9", db=0x7f1a7c015408 "test", table_name=0x7f1acc6fe0b0 "#sql-151a_9", open_in_engine=true) at /data/src/bb-10.3-temporal/sql/temporary_tables.cc:78
#14 0x000055f7f5401ea1 in mysql_alter_table (thd=0x7f1a7c000b00, new_db=0x7f1a7c015408 "test", new_name=0x0, create_info=0x7f1acc6fec90, table_list=0x7f1a7c014dd0, alter_info=0x7f1acc6febe0, order_num=0, order=0x0, ignore=false) at /data/src/bb-10.3-temporal/sql/sql_table.cc:9773
#15 0x000055f7f548a75f in Sql_cmd_alter_table::execute (this=0x7f1a7c015928, thd=0x7f1a7c000b00) at /data/src/bb-10.3-temporal/sql/sql_alter.cc:331
#16 0x000055f7f532ca37 in mysql_execute_command (thd=0x7f1a7c000b00) at /data/src/bb-10.3-temporal/sql/sql_parse.cc:6258
#17 0x000055f7f5331576 in mysql_parse (thd=0x7f1a7c000b00, rawbuf=0x7f1a7c014c58 "ALTER TABLE t1 PARTITION BY system_time INTERVAL 1 HOUR (PARTITION p1 HISTORY, PARTITION pn CURRENT)", length=100, parser_state=0x7f1acc7005f0, is_com_multi=false, is_next_command=false) at /data/src/bb-10.3-temporal/sql/sql_parse.cc:7988
#18 0x000055f7f531ed39 in dispatch_command (command=COM_QUERY, thd=0x7f1a7c000b00, packet=0x7f1a7c161211 "ALTER TABLE t1 PARTITION BY system_time INTERVAL 1 HOUR (PARTITION p1 HISTORY, PARTITION pn CURRENT)", packet_length=100, is_com_multi=false, is_next_command=false) at /data/src/bb-10.3-temporal/sql/sql_parse.cc:1826
#19 0x000055f7f531d76d in do_command (thd=0x7f1a7c000b00) at /data/src/bb-10.3-temporal/sql/sql_parse.cc:1371
#20 0x000055f7f54852d8 in do_handle_one_connection (connect=0x55f7f85a8c00) at /data/src/bb-10.3-temporal/sql/sql_connect.cc:1420
#21 0x000055f7f5485065 in handle_one_connection (arg=0x55f7f85a8c00) at /data/src/bb-10.3-temporal/sql/sql_connect.cc:1326
#22 0x000055f7f591b58e in pfs_spawn_thread (arg=0x55f7f864b3d0) at /data/src/bb-10.3-temporal/storage/perfschema/pfs.cc:1863
#23 0x00007f1adb7f7494 in start_thread (arg=0x7f1acc701700) at pthread_create.c:333
#24 0x00007f1ad9bdd93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Note: The problem apparently starts with a (timed) deadlock between these two threads. The deadlock itself should probably be looked into too, but it is not specific to versioning, while m_lock_type issue seems to only affect versioning partitioning.


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