[MDEV-22759] Failing assertion: !cursor->index->is_committed() upon update on table with HASH index Created: 2020-05-31  Updated: 2023-11-22

Status: Confirmed
Project: MariaDB Server
Component/s: Server, Storage Engine - InnoDB
Affects Version/s: 10.4, 10.5, 10.6, 10.7
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Unresolved Votes: 0
Labels: affects-tests, not-10.5+

Issue Links:
Problem/Incident
is caused by MDEV-371 Unique indexes for blobs Closed
Relates
relates to MDEV-28192 ERROR 1901 During ALTER Leading to fr... Closed
relates to MDEV-9663 InnoDB assertion failure: *cursor->in... Closed
relates to MDEV-14643 InnoDB: Failing assertion: !cursor->... Closed
relates to MDEV-19338 InnoDB: Failing assertion: !cursor->i... Closed
relates to MDEV-19775 Bug in WSREP/Galera with virtual colu... Closed
relates to MDEV-22061 InnoDB: Assertion of missing row in s... Closed
relates to MDEV-22076 InnoDB: Failing assertion: !cursor->i... Closed
relates to MDEV-22373 Unable to find a record to delete-mar... Closed
relates to MDEV-22739 !cursor->index->is_committed() in row... Closed
relates to MDEV-23713 Replication stops with "Index for tab... Stalled
relates to MDEV-28138 MariaDB Assertion Failed in mtr_buf_t... Closed

 Description   

There are other infamous bugs for this assertion failure, this one probably doesn't explain any of them, unless somebody can come up with a scenario when an InnoDB table in pre-MDEV-371 versions would use a HASH key. Still, I'll link the other bugs for this assertion failure to it, so that it's easier to see all the alternatives when we ask users about specifics of their data.

--source include/have_innodb.inc
 
 
 
CREATE TABLE t1 (
 
  a INT NOT NULL AUTO_INCREMENT,
 
  b char(8) NOT NULL DEFAULT '',
 
  UNIQUE KEY (b),
 
  UNIQUE KEY (a) USING HASH
 
) ENGINE=InnoDB;
 
 
 
INSERT INTO t1 (b) VALUES ('');
 
UPDATE t1 SET a = 0;
 
 
 
# Cleanup
 
DROP TABLE t1;

10.4 non-debug 6da14d7b

 
2020-05-31 14:49:03 9 [ERROR] InnoDB: Record in index `a` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {[8]        (0x00000104000002D0),[8]        (0x2020202020202020)} at: COMPACT RECORD(info_bits=0, 2 fields): {[8]        (0x00000104000002C4),[8]        (0x2020202020202020)}
 
2020-05-31 14:49:03 0x7fb7a5468700  InnoDB: Assertion failure in file /data/src/10.4/storage/innobase/row/row0ins.cc line 218
 
InnoDB: Failing assertion: !cursor->index->is_committed()
 
 
 
#6  0x000055698a2428f2 in ut_dbg_assertion_failed (expr=expr@entry=0x55698ad8cd28 "!cursor->index->is_committed()", file=file@entry=0x55698ad8c840 "/data/src/10.4/storage/innobase/row/row0ins.cc", line=line@entry=218) at /data/src/10.4/storage/innobase/ut/ut0dbg.cc:60
 
#7  0x000055698a79c4f1 in row_ins_sec_index_entry_by_modify (mtr=0x7fb7a5463eb0, thr=0x7fb758045d98, entry=0x7fb758047bc8, heap=0x7fb758048440, offsets_heap=<optimized out>, offsets=0x7fb7a5462fc8, cursor=0x7fb7a54630a0, mode=2, flags=0) at /data/src/10.4/storage/innobase/row/row0ins.cc:218
 
#8  row_ins_sec_index_entry_low (flags=flags@entry=0, mode=mode@entry=2, index=index@entry=0x7fb758084748, offsets_heap=<optimized out>, offsets_heap@entry=0x7fb758047fd0, heap=heap@entry=0x7fb758048440, entry=entry@entry=0x7fb758047bc8, trx_id=0, thr=0x7fb758045d98) at /data/src/10.4/storage/innobase/row/row0ins.cc:3056
 
#9  0x000055698a79c9de in row_ins_sec_index_entry (index=index@entry=0x7fb758084748, entry=0x7fb758047bc8, thr=thr@entry=0x7fb758045d98, check_foreign=<optimized out>) at /data/src/10.4/storage/innobase/row/row0ins.cc:3271
 
#10 0x000055698a7d3417 in row_upd_sec_index_entry (node=node@entry=0x7fb7580c8a50, thr=thr@entry=0x7fb758045d98) at /data/src/10.4/storage/innobase/row/row0upd.cc:2520
 
#11 0x000055698a7d8acd in row_upd_sec_step (thr=0x7fb758045d98, node=0x7fb7580c8a50) at /data/src/10.4/storage/innobase/row/row0upd.cc:2547
 
#12 row_upd (thr=0x7fb758045d98, node=0x7fb7580c8a50) at /data/src/10.4/storage/innobase/row/row0upd.cc:3327
 
#13 row_upd_step (thr=thr@entry=0x7fb758045d98) at /data/src/10.4/storage/innobase/row/row0upd.cc:3442
 
#14 0x000055698a7aef34 in row_update_for_mysql (prebuilt=0x7fb7580c7f88) at /data/src/10.4/storage/innobase/row/row0mysql.cc:1889
 
#15 0x000055698a6ed4ff in ha_innobase::update_row (this=0x7fb7580c77b0, old_row=0x7fb7580815e0 "\377\001", new_row=0x7fb7580815c8 "\377") at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:8816
 
#16 0x000055698a547b85 in handler::ha_update_row (this=0x7fb7580c77b0, old_data=0x7fb7580815e0 "\377\001", new_data=0x7fb7580815c8 "\377") at /data/src/10.4/sql/handler.cc:6764
 
#17 0x000055698a3d4949 in mysql_update (thd=thd@entry=0x7fb7580009a8, table_list=<optimized out>, fields=..., values=..., conds=<optimized out>, order_num=<optimized out>, order=<optimized out>, limit=18446744073709551615, ignore=false, found_return=0x7fb7a5465880, updated_return=0x7fb7a5465940) at /data/src/10.4/sql/sql_update.cc:1056
 
#18 0x000055698a32c535 in mysql_execute_command (thd=thd@entry=0x7fb7580009a8) at /data/src/10.4/sql/sql_parse.cc:4376
 
#19 0x000055698a3311ca in mysql_parse (thd=thd@entry=0x7fb7580009a8, rawbuf=<optimized out>, length=19, parser_state=parser_state@entry=0x7fb7a5467580, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.4/sql/sql_parse.cc:7901
 
#20 0x000055698a333474 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7fb7580009a8, packet=packet@entry=0x7fb758007a19 "UPDATE t1 SET a = 0", packet_length=packet_length@entry=19, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.4/sql/sql_parse.cc:1842
 
#21 0x000055698a334cd6 in do_command (thd=0x7fb7580009a8) at /data/src/10.4/sql/sql_parse.cc:1360
 
#22 0x000055698a4128a2 in do_handle_one_connection (connect=connect@entry=0x55698ca8c308) at /data/src/10.4/sql/sql_connect.cc:1412
 
#23 0x000055698a41295d in handle_one_connection (arg=arg@entry=0x55698ca8c308) at /data/src/10.4/sql/sql_connect.cc:1316
 
#24 0x000055698aa54261 in pfs_spawn_thread (arg=0x55698c793388) at /data/src/10.4/storage/perfschema/pfs.cc:1869
 
#25 0x00007fb7ad3164a4 in start_thread (arg=0x7fb7a5468700) at pthread_create.c:456
 
#26 0x00007fb7ac394d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

10.4 debug 6da14d7b

 
2020-05-31 14:50:32 9 [ERROR] InnoDB: Record in index `a` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {[8]        (0x00000104000002D0),[8]        (0x2020202020202020)} at: COMPACT RECORD(info_bits=0, 2 fields): {[8]        (0x00000104000002C4),[8]        (0x2020202020202020)}
 
mysqld: /data/src/10.4/storage/innobase/row/row0upd.cc:2423: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `btr_validate_index(index, 0)' failed.
 
200531 14:50:32 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007fe555394f12 in __GI___assert_fail (assertion=0x55cb6b7b38cd "btr_validate_index(index, 0)", file=0x55cb6b7b3130 "/data/src/10.4/storage/innobase/row/row0upd.cc", line=2423, function=0x55cb6b7b5fa0 <row_upd_sec_index_entry(upd_node_t*, que_thr_t*)::__PRETTY_FUNCTION__> "dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*)") at assert.c:101
 
#8  0x000055cb6afb6b3a in row_upd_sec_index_entry (node=0x7fe504146d08, thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:2423
 
#9  0x000055cb6afb74e2 in row_upd_sec_step (node=0x7fe504146d08, thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:2547
 
#10 0x000055cb6afba4e0 in row_upd (node=0x7fe504146d08, thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:3327
 
#11 0x000055cb6afba926 in row_upd_step (thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:3442
 
#12 0x000055cb6af5857f in row_update_for_mysql (prebuilt=0x7fe504146200) at /data/src/10.4/storage/innobase/row/row0mysql.cc:1889
 
#13 0x000055cb6adb0f76 in ha_innobase::update_row (this=0x7fe50400b868, old_row=0x7fe50400b428 "\377\001", new_row=0x7fe50400b410 "\377") at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:8816
 
#14 0x000055cb6ab729a6 in handler::ha_update_row (this=0x7fe50400b868, old_data=0x7fe50400b428 "\377\001", new_data=0x7fe50400b410 "\377") at /data/src/10.4/sql/handler.cc:6764
 
#15 0x000055cb6a91a60b in mysql_update (thd=0x7fe504000af0, table_list=0x7fe504013270, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7fe54a6fde40, updated_return=0x7fe54a6fdf00) at /data/src/10.4/sql/sql_update.cc:1056
 
#16 0x000055cb6a80b94f in mysql_execute_command (thd=0x7fe504000af0) at /data/src/10.4/sql/sql_parse.cc:4376
 
#17 0x000055cb6a8179cf in mysql_parse (thd=0x7fe504000af0, rawbuf=0x7fe504013198 "UPDATE t1 SET a = 0", length=19, parser_state=0x7fe54a6fe570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7901
 
#18 0x000055cb6a803f59 in dispatch_command (command=COM_QUERY, thd=0x7fe504000af0, packet=0x7fe504156e41 "UPDATE t1 SET a = 0", packet_length=19, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
 
#19 0x000055cb6a8026fb in do_command (thd=0x7fe504000af0) at /data/src/10.4/sql/sql_parse.cc:1360
 
#20 0x000055cb6a98a78a in do_handle_one_connection (connect=0x55cb6dc9c5c0) at /data/src/10.4/sql/sql_connect.cc:1412
 
#21 0x000055cb6a98a4d9 in handle_one_connection (arg=0x55cb6dc9c5c0) at /data/src/10.4/sql/sql_connect.cc:1316
 
#22 0x000055cb6b387fe3 in pfs_spawn_thread (arg=0x55cb6dc1a570) at /data/src/10.4/storage/perfschema/pfs.cc:1869
 
#23 0x00007fe55731d4a4 in start_thread (arg=0x7fe54a6ff700) at pthread_create.c:456
 
#24 0x00007fe555451d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.4, 10.5.
Not reproducible on 10.3, because until MDEV-371 USING HASH was apparently ignored. Starting from MDEV-371, it makes a difference. It wasn't this assertion failure after the first push of MDEV-371, but SIGSEGV in row_sel_store_mysql_rec. I didn't bisect to find out when it mutated into the assertion failure, as it seems unimportant.

Slight tweaks in the table structure or DML can make the assertion failure go away and leave only the error "Record in index ... was not found".

 Comments   
Comment by Elena Stepanova [ 2020-09-22 ]

Affects tests in the sense that it doesn't allow to detect occurrences of the "true" MDEV-14643 problem, if there are still any.

Comment by Elena Stepanova [ 2020-10-16 ]

Variation with system versioning (maybe not needed) and unique blob.

--source include/have_innodb.inc
 
 
 
CREATE TABLE t1 (
 
  a varchar(8) DEFAULT NULL,
 
  f blob DEFAULT NULL,
 
  row_start bigint(20) unsigned GENERATED ALWAYS AS ROW START,
 
  row_end bigint(20) unsigned GENERATED ALWAYS AS ROW END,
 
  UNIQUE KEY f (f),
 
  PERIOD FOR SYSTEM_TIME (row_start, row_end)
 
) ENGINE=InnoDB WITH SYSTEM VERSIONING;
 
 
 
INSERT INTO t1 (a) VALUES (NULL);
 
 
 
CREATE TABLE t2 (a VARCHAR(8)) ENGINE=InnoDB;
 
INSERT INTO t2 VALUES ('foo'),('bar'),('foo');
 
 
 
UPDATE t1 JOIN t2 SET t1.f = t2.a;

Comment by Elena Stepanova [ 2021-01-27 ]

More variations of errors:

--source include/have_innodb.inc
 
 
 
CREATE TABLE `t1` (
 
  `id` int(11) NOT NULL AUTO_INCREMENT,
 
  `a` char(127) DEFAULT '',
 
  `b` int(11) DEFAULT NULL,
 
  `c` varchar(3829) DEFAULT '',
 
  `d` int(11) DEFAULT NULL,
 
  PRIMARY KEY (`id`),
 
  UNIQUE KEY `a` (`a`(64),`c`) USING HASH,
 
  KEY `d` (`d`),
 
  KEY `b` (`b`,`a`),
 
  CONSTRAINT `x` FOREIGN KEY (`b`) REFERENCES `t1` (`d`)
 
) ENGINE=InnoDB;
 
 
 
SET SESSION FOREIGN_KEY_CHECKS = OFF;
 
INSERT INTO t1 VALUES (1, 'foo', 2, 'baz', 2),(2, NULL, 2, 'bar', 2);
 
REPLACE INTO t1 VALUES (1, 'foo', 2, 'baz', 2),(2, NULL, 2, 'bar', 2);
 
--sleep 3
 
DROP TABLE t1;

10.4 ce141d07

 
2021-01-27 21:01:30 3 [ERROR] InnoDB: tried to purge non-delete-marked record in index `a` of table `test`.`t1`: tuple: TUPLE (info_bits=0, 2 fields): {[8]        (0x881A87159489C7B6),[4]    (0x80000001)}, record: COMPACT RECORD(info_bits=0, 2 fields): {[8]        (0x881A87159489C7B6),[4]    (0x80000001)}
 
mysqld: /data/src/10.4/storage/innobase/row/row0purge.cc:599: bool row_purge_remove_sec_if_poss_leaf(purge_node_t*, dict_index_t*, const dtuple_t*): Assertion `0' failed.
 
210127 21:01:30 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007fb28fc6ef36 in __GI___assert_fail (assertion=0x55f86dba606c "0", file=0x55f86dba7050 "/data/src/10.4/storage/innobase/row/row0purge.cc", line=599, function=0x55f86dba7450 "bool row_purge_remove_sec_if_poss_leaf(purge_node_t*, dict_index_t*, const dtuple_t*)") at assert.c:101
 
#8  0x000055f86d3b9f3e in row_purge_remove_sec_if_poss_leaf (node=0x55f870c93f80, index=0x7fb22c044f80, entry=0x7fb244011a70) at /data/src/10.4/storage/innobase/row/row0purge.cc:599
 
#9  0x000055f86d3ba2c5 in row_purge_remove_sec_if_poss (node=0x55f870c93f80, index=0x7fb22c044f80, entry=0x7fb244011a70) at /data/src/10.4/storage/innobase/row/row0purge.cc:695
 
#10 0x000055f86d3ba4e8 in row_purge_del_mark (node=0x55f870c93f80) at /data/src/10.4/storage/innobase/row/row0purge.cc:769
 
#11 0x000055f86d3bc134 in row_purge_record_func (node=0x55f870c93f80, undo_rec=0x55f870c94520 "", thr=0x55f870c93db0, updated_extern=false) at /data/src/10.4/storage/innobase/row/row0purge.cc:1195
 
#12 0x000055f86d3bc456 in row_purge (node=0x55f870c93f80, undo_rec=0x55f870c94520 "", thr=0x55f870c93db0) at /data/src/10.4/storage/innobase/row/row0purge.cc:1261
 
#13 0x000055f86d3bc6b5 in row_purge_step (thr=0x55f870c93db0) at /data/src/10.4/storage/innobase/row/row0purge.cc:1320
 
#14 0x000055f86d3277ec in que_thr_step (thr=0x55f870c93db0) at /data/src/10.4/storage/innobase/que/que0que.cc:1038
 
#15 0x000055f86d327a84 in que_run_threads_low (thr=0x55f870c93db0) at /data/src/10.4/storage/innobase/que/que0que.cc:1100
 
#16 0x000055f86d327cea in que_run_threads (thr=0x55f870c93db0) at /data/src/10.4/storage/innobase/que/que0que.cc:1140
 
#17 0x000055f86d40623b in srv_task_execute (slot=0x55f86e1c6d78 <srv_sys+504>) at /data/src/10.4/storage/innobase/srv/srv0srv.cc:2471
 
#18 0x000055f86d40646d in srv_worker_thread (arg=0x0) at /data/src/10.4/storage/innobase/srv/srv0srv.cc:2519
 
#19 0x00007fb2904ef609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#20 0x00007fb28fd5a293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Comment by Oleksandr Byelkin [ 2022-06-21 ]

Original test case is not repeatable:

CREATE TABLE t1 (
 
a INT NOT NULL AUTO_INCREMENT,
 
b char(8) NOT NULL DEFAULT '',
 
UNIQUE KEY (b),
 
UNIQUE KEY (a) USING HASH
 
) ENGINE=InnoDB;
 
main.test 'innodb'                       [ fail ]
 
        Test ended at 2022-06-21 14:50:49
 
 
 
CURRENT_TEST: main.test
 
mysqltest: At line 4: query 'CREATE TABLE t1 (
 
a INT NOT NULL AUTO_INCREMENT,
 
b char(8) NOT NULL DEFAULT '',
 
UNIQUE KEY (b),
 
UNIQUE KEY (a) USING HASH
 
) ENGINE=InnoDB' failed: 1901: Function or expression 'AUTO_INCREMENT' cannot be used in the USING HASH clause of `a`

the other two do

Comment by Alice Sherepa [ 2023-09-28 ]

Both test cases from comments are still reproducible on 10.4, but not on 10.5+:

 
 
2023-09-28 18:49:57 0x7f11ac141300  InnoDB: Assertion failure in file /10.4/src/storage/innobase/row/row0ins.cc line 219
 
InnoDB: Failing assertion: !cursor->index->is_committed()
 
InnoDB: We intentionally generate a memory trap.
 
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
InnoDB: If you get repeated assertion failures or crashes, even
 
InnoDB: immediately after the mysqld startup, there may be
 
InnoDB: corruption in the InnoDB tablespace. Please refer to
 
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
 
InnoDB: about forcing recovery.
 
230928 18:49:57 [ERROR] mysqld got signal 6 ;
 
This could be because you hit a bug. It is also possible that this binary
 
or one of the libraries it was linked against is corrupt, improperly built,
 
or misconfigured. This error can also be caused by malfunctioning hardware.
 
 
 
Server version: 10.4.32-MariaDB-debug-log source revision: 50a2e8b1892b6b8a276d4bd75a1a02148f9e6ff2
 
 
 
sql/signal_handler.cc:238(handle_fatal_signal)[0x557e941767e9]
 
sigaction.c:0(__restore_rt)[0x7f11c2d16420]
 
ut/ut0dbg.cc:60(_sub_D_00099_0)[0x557e950a2a4e]
 
row/row0ins.cc:220(row_ins_sec_index_entry_by_modify(unsigned long, unsigned long, btr_cur_t*, unsigned short**, mem_block_info_t*, mem_block_info_t*, dtuple_t const*, que_thr_t*, mtr_t*))[0x557e94e8937d]
 
row/row0ins.cc:3149(row_ins_sec_index_entry_low(unsigned long, unsigned long, dict_index_t*, mem_block_info_t*, mem_block_info_t*, dtuple_t*, unsigned long, que_thr_t*))[0x557e94e99937]
 
row/row0ins.cc:3361(row_ins_sec_index_entry(dict_index_t*, dtuple_t*, que_thr_t*, bool))[0x557e94e9ad2a]
 
row/row0upd.cc:2571(row_upd_sec_index_entry(upd_node_t*, que_thr_t*))[0x557e94fa444e]
 
row/row0upd.cc:2598(row_upd_sec_step(upd_node_t*, que_thr_t*))[0x557e94fa498f]
 
row/row0upd.cc:3361(row_upd(upd_node_t*, que_thr_t*))[0x557e94fa9e02]
 
row/row0upd.cc:3476(row_upd_step(que_thr_t*))[0x557e94faa913]
 
row/row0mysql.cc:1804(row_update_for_mysql(row_prebuilt_t*))[0x557e94eeb17a]
 
handler/ha_innodb.cc:8954(ha_innobase::update_row(unsigned char const*, unsigned char const*))[0x557e94b74026]
 
sql/handler.cc:6915(handler::ha_update_row(unsigned char const*, unsigned char const*))[0x557e941b1bd7]
 
sql/sql_update.cc:2600(multi_update::send_data(List<Item>&))[0x557e93ca48b2]
 
sql/sql_select.cc:22098(end_send(JOIN*, st_join_table*, bool))[0x557e93b0d031]
 
sql/sql_select.cc:21129(evaluate_join_record(JOIN*, st_join_table*, int))[0x557e93b053df]
 
sql/sql_select.cc:20941(sub_select(JOIN*, st_join_table*, bool))[0x557e93b0437a]
 
sql/sql_select.cc:21129(evaluate_join_record(JOIN*, st_join_table*, int))[0x557e93b053df]
 
sql/sql_select.cc:20902(sub_select(JOIN*, st_join_table*, bool))[0x557e93b03d14]
 
sql/sql_select.cc:20423(do_select(JOIN*, Procedure*))[0x557e93b01aba]
 
sql/sql_select.cc:4605(JOIN::exec_inner())[0x557e93a8f602]
 
sql/sql_select.cc:4388(JOIN::exec())[0x557e93a8cc2e]
 
sql/sql_select.cc:4828(mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x557e93a90e0e]
 
sql/sql_update.cc:1970(mysql_multi_update(THD*, TABLE_LIST*, List<Item>*, List<Item>*, Item*, unsigned long long, enum_duplicates, bool, st_select_lex_unit*, st_select_lex*, multi_update**))[0x557e93c9e0b1]
 
sql/sql_parse.cc:4532(mysql_execute_command(THD*))[0x557e939be3bd]
 
sql/sql_parse.cc:8012(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x557e939d6c07]
 
sql/sql_parse.cc:1860(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x557e939ad02d]
 
sql/sql_parse.cc:1378(do_command(THD*))[0x557e939a9b58]
 
sql/sql_connect.cc:1420(do_handle_one_connection(CONNECT*))[0x557e93db77fd]
 
sql/sql_connect.cc:1325(handle_one_connection)[0x557e93db70a1]
 
perfschema/pfs.cc:1871(pfs_spawn_thread)[0x557e94a6199a]
 
nptl/pthread_create.c:478(start_thread)[0x7f11c2d0a609]
 
 
 
Query (0x62b0000a1290): UPDATE t1 JOIN t2 SET t1.f = t2.a

Comment by Nicholas Othieno [ 2023-11-22 ]

We observed a crash similar to this on 10.6.14 in a primary with read replica setup. The user bulk inserted about 4,000 records into as single table on their primary instance, and the read replica crashed while attempting to update a secondary hash index on the same index. The definition of the crashing table is:

CREATE TABLE `table1` (
 
  `field1` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
 
  `field2` date NOT NULL,
 
  `field3` int(11) NOT NULL,
 
  `field4` varchar(200) DEFAULT NULL,
 
  `field5` int(11) NOT NULL DEFAULT 0,
 
  `field6` varchar(200) NOT NULL DEFAULT '',
 
  `field7` int(11) NOT NULL,
 
  `field8` varchar(200) CHARACTER SET latin1 COLLATE latin1_swedish_ci DEFAULT NULL,
 
  `field9` varchar(20) DEFAULT NULL,
 
  `field10` varchar(200) DEFAULT '',
 
  `field11` varchar(200) DEFAULT '',
 
  `field12` varchar(800) DEFAULT '',
 
  `field13` varchar(200) DEFAULT '',
 
  `field14` varchar(800) DEFAULT '',
 
  `field15` int(11) NOT NULL,
 
  `field16` int(11) NOT NULL,
 
  `field18` decimal(15,5) NOT NULL,
 
  PRIMARY KEY (`field1`),
 
  UNIQUE KEY `field1_INDEX` (`field1`),
 
  UNIQUE KEY `sec_hash_INDEX` (`field2`,`field3`,`field7`,`field11`,`field13`,`field14`,`field10`,`field12`,`field9`,`field5`) USING HASH,
 
  KEY `field3_INDEX` (`field3`),
 
  KEY `field11_INDEX` (`field11`),
 
  KEY `field14_INDEX` (`field14`(768)),
 
  KEY `field2_INDEX` (`field2`),
 
  KEY `field5_INDEX` (`field5`)
 
) ENGINE=InnoDB AUTO_INCREMENT=79021905 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

The read replica crashes when updating the hash index `sec_hash_INDEX`.

When we looked at other MariaDB jiras, we thought that MDEV-27751 might be a match as well considering the comment by marko that linked MDEV-27751 to an issue with bulk inserts:

I suspect that this has something to do with MDEV-24621.
Perhaps the MDEV-24622 limitation was not being enforced?

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