[MDEV-31792] Assertion fails in MDL_context::acquire_lock upon parallel replication of CREATE SEQUENCE Created: 2023-07-28  Updated: 2023-12-27  Resolved: 2023-10-23

Status: Closed
Project: MariaDB Server
Component/s: Replication, Sequences
Affects Version/s: 10.5, 10.6, 10.9, 10.10, 10.11, 11.0, 11.1
Fix Version/s: 10.4.32, 10.5.23, 10.6.16, 10.10.7, 10.11.6, 11.0.4, 11.1.3, 11.2.2, 11.3.1

Type: Bug Priority: Blocker
Reporter: Elena Stepanova Assignee: Andrei Elkin
Resolution: Fixed Votes: 0
Labels: None


 Description   

The test case is non-deterministic, run with --repeat=N or increase the value of $run variable in the test case. It currently fails for me on (nearly) every attempt, but it can vary on different machines and builds.
Don't put it into the regression suite!

--source include/have_innodb.inc
 
--source include/master-slave.inc
 
 
 
--connection slave
 
STOP SLAVE;
 
SET @parallel.save= @@slave_parallel_threads;
 
SET GLOBAL slave_parallel_threads= 4;
 
START SLAVE;
 
 
 
--connection master
 
--let $run= 100
 
while ($run)
 
{
 
  CREATE OR REPLACE SEQUENCE s ENGINE=InnoDB;
 
  --dec $run
 
}
 
 
 
--sync_slave_with_master
 
 
 
# Cleanup
 
STOP SLAVE;
 
SET GLOBAL slave_parallel_threads= @parallel.save;
 
START SLAVE;
 
--connection master
 
DROP SEQUENCE s;
 
--source include/rpl_end.inc

10.5 1a5c4c2d

 
mariadbd: /data/src/10.5/sql/mdl.cc:2353: bool MDL_context::acquire_lock(MDL_request*, double): Assertion `(mdl_request->type != MDL_INTENTION_EXCLUSIVE && mdl_request-
 
>type != MDL_EXCLUSIVE) || !(get_thd()->rgi_slave && get_thd()->rgi_slave->is_parallel_exec && lock->check_if_conflicting_replication_locks(this))' failed.
 
230728 18:41:30 [ERROR] mysqld got signal 6 ;
 
 
 
#9  0x00007f555e253df2 in __GI___assert_fail (assertion=0x555c4fb7a900 "(mdl_request->type != MDL_INTENTION_EXCLUSIVE && mdl_request->type != MDL_EXCLUSIVE) || !(get_thd()->rgi_slave && get_thd()->rgi_slave->is_parallel_exec && lock->check_if_conflicting_replication_locks"..., file=0x555c4fb79300 "/data/src/10.5/sql/mdl.cc", line=2353, function=0x555c4fb7aa00 "bool MDL_context::acquire_lock(MDL_request*, double)") at ./assert/assert.c:101
 
#10 0x0000555c4de021dc in MDL_context::acquire_lock (this=0x62b000150360, mdl_request=0x62b0001577c0, lock_wait_timeout=31536000) at /data/src/10.5/sql/mdl.cc:2353
 
#11 0x0000555c4de033af in MDL_context::acquire_locks (this=0x62b000150360, mdl_requests=0x7f554fed2ee0, lock_wait_timeout=31536000) at /data/src/10.5/sql/mdl.cc:2519
 
#12 0x0000555c4d807da8 in lock_table_names (thd=0x62b000150218, options=..., tables_start=0x62b000157348, tables_end=0x0, lock_wait_timeout=31536000, flags=0) at /data/src/10.5/sql/sql_base.cc:4045
 
#13 0x0000555c4d808994 in open_tables (thd=0x62b000150218, options=..., start=0x7f554fed33e0, counter=0x7f554fed33d0, flags=0, prelocking_strategy=0x7f554fed34e0) at /data/src/10.5/sql/sql_base.cc:4260
 
#14 0x0000555c4d80dcb7 in open_and_lock_tables (thd=0x62b000150218, options=..., tables=0x62b000157348, derived=false, flags=0, prelocking_strategy=0x7f554fed34e0) at /data/src/10.5/sql/sql_base.cc:5237
 
#15 0x0000555c4dc6321b in open_and_lock_tables (thd=0x62b000150218, options=..., tables=0x62b000157348, derived=false, flags=0) at /data/src/10.5/sql/sql_base.h:499
 
#16 0x0000555c4dc2d4fb in mysql_create_table (thd=0x62b000150218, create_table=0x62b000157348, create_info=0x7f554fed38f0, alter_info=0x7f554fed37e0) at /data/src/10.5/sql/sql_table.cc:5578
 
#17 0x0000555c4dc5f7c1 in Sql_cmd_create_table_like::execute (this=0x62b000157318, thd=0x62b000150218) at /data/src/10.5/sql/sql_table.cc:12380
 
#18 0x0000555c4d9ac5ef in mysql_execute_command (thd=0x62b000150218) at /data/src/10.5/sql/sql_parse.cc:6073
 
#19 0x0000555c4d9b9aab in mysql_parse (thd=0x62b000150218, rawbuf=0x60f0000191a3 "CREATE OR REPLACE SEQUENCE s ENGINE=InnoDB", length=42, parser_state=0x7f554fed4750, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8106
 
#20 0x0000555c4e51b3df in Query_log_event::do_apply_event (this=0x6130000e0ad8, rgi=0x61d00031d880, query_arg=0x60f0000191a3 "CREATE OR REPLACE SEQUENCE s ENGINE=InnoDB", q_len_arg=42) at /data/src/10.5/sql/log_event_server.cc:1917
 
#21 0x0000555c4e51859f in Query_log_event::do_apply_event (this=0x6130000e0ad8, rgi=0x61d00031d880) at /data/src/10.5/sql/log_event_server.cc:1595
 
#22 0x0000555c4d72e24c in Log_event::apply_event (this=0x6130000e0ad8, rgi=0x61d00031d880) at /data/src/10.5/sql/log_event.h:1488
 
#23 0x0000555c4d70df08 in apply_event_and_update_pos_apply (ev=0x6130000e0ad8, thd=0x62b000150218, rgi=0x61d00031d880, reason=0) at /data/src/10.5/sql/slave.cc:3853
 
#24 0x0000555c4d70ecf8 in apply_event_and_update_pos_for_parallel (ev=0x6130000e0ad8, thd=0x62b000150218, rgi=0x61d00031d880) at /data/src/10.5/sql/slave.cc:4039
 
#25 0x0000555c4df222c3 in rpt_handle_event (qev=0x619000140a98, rpt=0x61d0003170d8) at /data/src/10.5/sql/rpl_parallel.cc:61
 
#26 0x0000555c4df29e96 in handle_rpl_parallel_thread (arg=0x61d0003170d8) at /data/src/10.5/sql/rpl_parallel.cc:1383
 
#27 0x0000555c4ea220e2 in pfs_spawn_thread (arg=0x615000050818) at /data/src/10.5/storage/perfschema/pfs.cc:2201
 
#28 0x00007f555e2a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
 
#29 0x00007f555e3285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Reproducible on 10.5+.
Could not reproduce on 10.4.
No obvious immediate problem on a non-debug build.

 Comments   
Comment by Andrei Elkin [ 2023-10-23 ]

Howdy Brandon.
The patch is in bb-10.4-andrei. Could you please attend it the soonest (that's the user's plea).

Thank you.

Andrei

Comment by Michael Widenius [ 2023-10-23 ]

Review:

Please add () around the & arguments (could give warnings with some compilers)
DBUG_ASSERT(thd_arg->lex->sql_command != SQLCOM_CREATE_SEQUENCE ||
flags2 & FL_DDL);

Otherwise ok.
(The code added is similar to other related code in other places)

Comment by Brandon Nesterenko [ 2023-10-23 ]

428c49a4f approved.

Comment by Andrei Elkin [ 2023-10-23 ]

10.4 is fixed too, as the description test eventually failed for me.

Comment by Michael Widenius [ 2023-10-23 ]

This issue could happen if there where multiple CREATE SEQUENCE or CREATE OR REPLACE sequence command executed at the same time on slave with parallel execution enabled.
This bug affects all 10.5 and newer MariaDB versions.

The reason for the bug was that parallel slave tried to run CREATE SEQUENCE in parallel, which it should not do.
The fix is to stop parallel slave to allow new statements to be run before CREATE SEQUENCE is done.

Generated at Thu Feb 08 10:26:30 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.