[MDEV-27368] crash in recovery after creating incorrect foreign constraint Created: 2021-12-26  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.7
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Major
Reporter: Eugene Kosov (Inactive) Assignee: Thirunarayanan Balathandayuthapani
Resolution: Unresolved Votes: 0
Labels: crash, foreign-keys, innodb, recovery


 Description   

--source include/have_innodb.inc
 
CREATE TABLE t1 (id INT PRIMARY KEY, a INT UNIQUE, b INT UNIQUE, data INT) ENGINE=INNODB;
INSERT INTO t1 VALUES (1, 1, 1, 100500);
INSERT INTO t1 VALUES (2, 2, 2, 100500);
 
SET SESSION foreign_key_checks=OFF;
ALTER TABLE t1 ADD FOREIGN KEY (a) REFERENCES t1 (a) ON UPDATE NO ACTION, ALGORITHM=COPY;
SET SESSION foreign_key_checks=ON;
 
connect (con1,localhost,root,,);
BEGIN;
UPDATE t1 SET data=500100 WHERE a=1 AND b=1;
 
connection default;
SET GLOBAL innodb_flush_log_at_trx_commit=1;
UPDATE t1 SET data=1234 WHERE a=2 AND b=2	;
 
let $shutdown_timeout=0;
--source include/restart_mysqld.inc
 
disconnect con1;
 
DROP TABLE t1;

Thread 1 (Thread 0x7f6109df6640 (LWP 1416385)):
#0  __pthread_kill (threadid=<optimized out>, signo=6) at pthread_kill.c:54
#1  0x000000000173ac37 in my_write_core (sig=6) at stacktrace.c:386
#2  0x0000000000be1fce in handle_fatal_signal (sig=6) at signal_handler.cc:355
#3  <signal handler called>
#4  __GI_raise (sig=sig@entry=6) at raise.c:49
#5  0x00007f611455b536 in __GI_abort () at abort.c:79
#6  0x00007f611455b41f in __assert_fail_base (fmt=0x7f61146c1998 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5abd66 "lock_table_has_locks(index->table)", file=0x587d30 "/home/kevgs/work/m/bb-10.3-kevgs/storage/innobase/row/row0umod.cc", line=239, function=<optimized out>) at assert.c:92
#7  0x00007f611456a212 in __GI___assert_fail (assertion=0x5abd66 "lock_table_has_locks(index->table)", file=0x587d30 "/home/kevgs/work/m/bb-10.3-kevgs/storage/innobase/row/row0umod.cc", line=239, function=0x4a4be8 "dberr_t row_undo_mod_clust(undo_node_t *, que_thr_t *)") at assert.c:101
#8  0x00000000014f72a9 in row_undo_mod_clust (node=0x7f60f8001690, thr=0x7f60f80014c0) at row0umod.cc:239
#9  0x00000000014f589d in row_undo_mod (node=0x7f60f8001690, thr=0x7f60f80014c0) at row0umod.cc:1331
#10 0x00000000014ee1a2 in row_undo (node=0x7f60f8001690, thr=0x7f60f80014c0) at row0undo.cc:308
#11 0x00000000014edcea in row_undo_step (thr=0x7f60f80014c0) at row0undo.cc:362
#12 0x0000000001408b08 in que_thr_step (thr=0x7f60f80014c0) at que0que.cc:1036
#13 0x0000000001407c80 in que_run_threads_low (thr=0x7f60f80014c0) at que0que.cc:1100
#14 0x00000000014079b7 in que_run_threads (thr=0x7f60f80014c0) at que0que.cc:1140
#15 0x000000000157c7c6 in trx_rollback_active (trx=0x7f61124c90c0) at trx0roll.cc:649
#16 0x000000000157c1cc in trx_rollback_recovered (all=true) at trx0roll.cc:806
#17 0x000000000157cd59 in trx_rollback_all_recovered () at trx0roll.cc:861
#18 0x00007f6114706d80 in start_thread (arg=0x7f6109df6640) at pthread_create.c:481
#19 0x00007f6114631b6f in clone () at clone.S:95


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