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
CREATETABLE t (pk INTPRIMARYKEY, f varchar(1024)) ENGINE=InnoDB;
INSERTINTO t SELECT seq, REPEAT(CHR(seq%26+97),1024) FROM seq_1_to_10000;
#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-15250UPSERT during ALTER-TABLE results in 'Duplicate entry' error for alter