Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
N/A
Description
Filing separately from MDEV-26198 because this one seems to be a recent regression.
The test case is non-deterministic, run with --repeat. It currently fails very well for me (usually on the 1st attempt or within a few), but it can vary on different machines and builds. Try to modify --sleep if it doesn't fail.
--source include/have_innodb.inc
|
--source include/have_sequence.inc
|
|
CREATE TABLE t (pk INT PRIMARY KEY, f varchar(1024)) ENGINE=InnoDB; |
INSERT INTO t SELECT seq, REPEAT(CHR(seq%26+97),1024) FROM seq_1_to_10000; |
|
--connect (con1,localhost,root,,test)
|
--send
|
ALTER TABLE t ADD KEY (f); |
|
--connection default
|
--sleep 0.2
|
UPDATE t SET f = 'foo'; |
|
--connection con1
|
--reap
|
|
# Cleanup
|
DROP TABLE t; |
--disconnect con1 |
10.6 a42e327a |
mariadbd: /data/src/10.6/storage/innobase/row/row0log.cc:3290: const mrec_t* row_log_apply_op(dict_index_t*, row_merge_dup_t*, dberr_t*, mem_heap_t*, mem_heap_t*, bool, const mrec_t*, const mrec_t*, rec_offs*): Assertion `index->lock.have_x() == has_index_lock' failed.
|
220502 1:59:57 [ERROR] mysqld got signal 6 ;
|
|
#7 0x00007f423bf82662 in __GI___assert_fail (assertion=0x5600cba65b58 "index->lock.have_x() == has_index_lock", file=0x5600cba63b28 "/data/src/10.6/storage/innobase/row/row0log.cc", line=3290, function=0x5600cba65d20 "const mrec_t* row_log_apply_op(dict_index_t*, row_merge_dup_t*, dberr_t*, mem_heap_t*, mem_heap_t*, bool, const mrec_t*, const mrec_t*, rec_offs*)") at assert.c:101
|
#8 0x00005600cb305001 in row_log_apply_op (index=0x7f41dc021388, dup=0x7f42352ca590, error=0x7f42352ca35c, offsets_heap=0x7f41dc53ef78, heap=0x7f41dc070d18, has_index_lock=false, mrec=0x7f42343a6000 "b\003", mrec_end=0x7f42344a6000 'd' <repeats 200 times>..., offsets=0x7f41dc0201c8) at /data/src/10.6/storage/innobase/row/row0log.cc:3290
|
#9 0x00005600cb307033 in row_log_apply_ops (trx=0x7f42365c4680, index=0x7f41dc021388, dup=0x7f42352ca590, stage=0x7f41dc020158) at /data/src/10.6/storage/innobase/row/row0log.cc:3632
|
#10 0x00005600cb307766 in row_log_apply (trx=0x7f42365c4680, index=0x7f41dc021388, table=0x7f42352cb2f0, stage=0x7f41dc020158) at /data/src/10.6/storage/innobase/row/row0log.cc:3744
|
#11 0x00005600cb181dfa in ha_innobase::commit_inplace_alter_table (this=0x7f41d821da70, altered_table=0x7f42352cb2f0, ha_alter_info=0x7f42352cb230, commit=true) at /data/src/10.6/storage/innobase/handler/handler0alter.cc:11036
|
#12 0x00005600cad23670 in handler::ha_commit_inplace_alter_table (this=0x7f41d821da70, altered_table=0x7f42352cb2f0, ha_alter_info=0x7f42352cb230, commit=true) at /data/src/10.6/sql/handler.cc:5218
|
#13 0x00005600caa856c2 in mysql_inplace_alter_table (thd=0x7f41dc000db8, table_list=0x7f41dc014238, table=0x7f41d8237f38, altered_table=0x7f42352cb2f0, ha_alter_info=0x7f42352cb230, target_mdl_request=0x7f42352cbb30, ddl_log_state=0x7f42352cb1d0, trigger_param=0x7f42352cb6e0, alter_ctx=0x7f42352cc690) at /data/src/10.6/sql/sql_table.cc:7471
|
#14 0x00005600caa8e0d0 in mysql_alter_table (thd=0x7f41dc000db8, new_db=0x7f41dc0059b8, new_name=0x7f41dc005dd0, create_info=0x7f42352cd4a0, table_list=0x7f41dc014238, alter_info=0x7f42352cd3b0, order_num=0, order=0x0, ignore=false, if_exists=false) at /data/src/10.6/sql/sql_table.cc:10267
|
#15 0x00005600cab41c92 in Sql_cmd_alter_table::execute (this=0x7f41dc0149f8, thd=0x7f41dc000db8) at /data/src/10.6/sql/sql_alter.cc:542
|
#16 0x00005600ca98bd0a in mysql_execute_command (thd=0x7f41dc000db8, is_called_from_prepared_stmt=false) at /data/src/10.6/sql/sql_parse.cc:6012
|
#17 0x00005600ca991d68 in mysql_parse (thd=0x7f41dc000db8, rawbuf=0x7f41dc014160 "ALTER TABLE t ADD KEY (f)", length=25, parser_state=0x7f42352ce500) at /data/src/10.6/sql/sql_parse.cc:8045
|
#18 0x00005600ca97e3bb in dispatch_command (command=COM_QUERY, thd=0x7f41dc000db8, packet=0x7f41dc00b879 "", packet_length=25, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1912
|
#19 0x00005600ca97cce8 in do_command (thd=0x7f41dc000db8, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1409
|
#20 0x00005600cab36c5c in do_handle_one_connection (connect=0x5600ce6344c8, put_in_cache=true) at /data/src/10.6/sql/sql_connect.cc:1418
|
#21 0x00005600cab368fb in handle_one_connection (arg=0x5600ce6344c8) at /data/src/10.6/sql/sql_connect.cc:1312
|
#22 0x00005600cb051182 in pfs_spawn_thread (arg=0x5600ce6345a8) at /data/src/10.6/storage/perfschema/pfs.cc:2201
|
#23 0x00007f423c44eea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#24 0x00007f423c04bdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
The failure most likely started happening on 10.6 after this commit:
commit 4b80c11f52a3da189bafd7a772bcbf3519ceb41e
|
Author: Thirunarayanan Balathandayuthapani
|
Date: Mon Apr 25 13:36:56 2022 +0530
|
|
MDEV-15250 UPSERT during ALTER TABLE results in 'Duplicate entry' error for alter
|
|
- InnoDB DDL results in `Duplicate entry' if concurrent DML throws
|
Attachments
Issue Links
- is caused by
-
MDEV-15250 UPSERT during ALTER-TABLE results in 'Duplicate entry' error for alter
- Closed