[MDEV-18057] Assertion `(node->state == 5) || (node->state == 6)' failed in row_upd_sec_step upon DELETE after UPDATE failed due to FK violation Created: 2018-12-21  Updated: 2019-10-09  Resolved: 2019-01-25

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3, 10.4
Fix Version/s: 10.4.3, 10.3.13

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Eugene Kosov (Inactive)
Resolution: Fixed Votes: 0
Labels: system_versioned_tables

Issue Links:
Relates
relates to MDEV-16210 FK constraints on versioned tables us... Closed

 Description   

Note: the test case involves versioning, so I can't check whether 10.2 is affected. It's quite possible that versioning is not necessary, and some other table structure would suffice, but I don't know what it should be.

--source include/have_innodb.inc
 
CREATE TABLE t1 (f1 INT, KEY(f1)) ENGINE=InnoDB;
CREATE TABLE t2 (f2 INT, FOREIGN KEY (f2) REFERENCES t1 (f1)) ENGINE=InnoDB WITH SYSTEM VERSIONING;
 
--connect (con1,localhost,root,,test)
SET FOREIGN_KEY_CHECKS= OFF;
INSERT IGNORE INTO t2 VALUES (1);
 
--connection default
--error ER_NO_REFERENCED_ROW_2
UPDATE t2 SET f2= 2;
DELETE FROM t2;
 
# Cleanup
--disconnect con1
--connection default
DROP TABLE t2, t1;

10.3 2999492c3

mysqld: /data/src/10.3/storage/innobase/row/row0upd.cc:2550: dberr_t row_upd_sec_step(upd_node_t*, que_thr_t*): Assertion `(node->state == 5) || (node->state == 6)' failed.
181221 19:21:02 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fcb3d890ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000558d7185a701 in row_upd_sec_step (node=0x7fcae801fc20, thr=0x7fcae801ff58) at /data/src/10.3/storage/innobase/row/row0upd.cc:2549
#9  0x0000558d7185cfb1 in row_upd (node=0x7fcae801fc20, thr=0x7fcae801ff58) at /data/src/10.3/storage/innobase/row/row0upd.cc:3323
#10 0x0000558d7185d319 in row_upd_step (thr=0x7fcae801ff58) at /data/src/10.3/storage/innobase/row/row0upd.cc:3438
#11 0x0000558d717ff740 in row_update_for_mysql (prebuilt=0x7fcae801f0e8) at /data/src/10.3/storage/innobase/row/row0mysql.cc:1888
#12 0x0000558d716a8de2 in ha_innobase::update_row (this=0x7fcae801e4d8, old_row=0x7fcae8006a28 "\375\001", new_row=0x7fcae8006a10 "\375\001") at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:8844
#13 0x0000558d7139181f in handler::ha_update_row (this=0x7fcae801e4d8, old_data=0x7fcae8006a28 "\375\001", new_data=0x7fcae8006a10 "\375\001") at /data/src/10.3/sql/handler.cc:6269
#14 0x0000558d715298e3 in TABLE::delete_row (this=0x7fcae801d890) at /data/src/10.3/sql/sql_delete.cc:260
#15 0x0000558d71526a83 in mysql_delete (thd=0x7fcae4000b00, table_list=0x7fcae4014da0, conds=0x0, order_list=0x7fcae4005398, limit=18446744073709551615, options=0, result=0x0) at /data/src/10.3/sql/sql_delete.cc:753
#16 0x0000558d7108ddcb in mysql_execute_command (thd=0x7fcae4000b00) at /data/src/10.3/sql/sql_parse.cc:4925
#17 0x0000558d71097ec9 in mysql_parse (thd=0x7fcae4000b00, rawbuf=0x7fcae4014cd8 "DELETE FROM t2", length=14, parser_state=0x7fcb32b9c5f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8092
#18 0x0000558d7108507d in dispatch_command (command=COM_QUERY, thd=0x7fcae4000b00, packet=0x7fcae400b1e1 "DELETE FROM t2", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1851
#19 0x0000558d71083aa1 in do_command (thd=0x7fcae4000b00) at /data/src/10.3/sql/sql_parse.cc:1396
#20 0x0000558d711ebab0 in do_handle_one_connection (connect=0x558d73cb9090) at /data/src/10.3/sql/sql_connect.cc:1402
#21 0x0000558d711eb834 in handle_one_connection (arg=0x558d73cb9090) at /data/src/10.3/sql/sql_connect.cc:1308
#22 0x0000558d7168610f in pfs_spawn_thread (arg=0x558d73cfaa30) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#23 0x00007fcb3f34c494 in start_thread (arg=0x7fcb32b9d700) at pthread_create.c:333
#24 0x00007fcb3d94d93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

No obvious failures on a non-debug build.



 Comments   
Comment by Marko Mäkelä [ 2019-01-18 ]

The assertion fails because node->state == UPD_NODE_UPDATE_CLUSTERED.

System versioning seems to be the culprit.
In row_upd_clust_step(), the assignment node->state = UPD_NODE_UPDATE_ALL_SEC; is being skipped unless node->is_delete == PLAIN_DELETE.

Generated at Thu Feb 08 08:41:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.