[MDEV-22548] Assertion `0' failed in Protocol::end_statement upon multi-table DELETE IGNORE from system- and application-versioned table Created: 2020-05-13  Updated: 2023-11-28

Status: Confirmed
Project: MariaDB Server
Component/s: Versioned Tables
Affects Version/s: 10.4, 10.5, 10.6, 10.9, 10.10, 10.11, 11.0
Fix Version/s: 10.4, 10.5, 10.6, 10.11, 11.0

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Nikita Malyavin
Resolution: Unresolved Votes: 0
Labels: application_time

Issue Links:
Blocks
Relates
relates to MDEV-25021 Assertion `0' failed in Protocol::end... Confirmed
relates to MDEV-22540 ER_DUP_ENTRY upon REPLACE or Assertio... Closed

 Description   

Note: I have no idea why t0 actions are important in the scenario, but they seem to be.

CREATE TABLE t0 (f INT, UNIQUE(f));
INSERT INTO t0 VALUES (1),(2);
UPDATE IGNORE t0 SET f = 3;
 
CREATE TABLE t1 (a INT, s TIMESTAMP, e TIMESTAMP, PERIOD FOR p(s,e), PRIMARY KEY(a)) ENGINE=MyISAM;
INSERT INTO t1 VALUES (1,'1977-05-21','2022-07-03');
ALTER TABLE t1 ADD SYSTEM VERSIONING;
 
CREATE TABLE t2 (b INT) ENGINE=MyISAM;
INSERT INTO t2 VALUES (NULL);
 
SET TIMESTAMP=1589301327.41775;
DELETE IGNORE FROM t1 FOR PORTION OF p FROM '1990-01-22' TO '2006-01-07';
DELETE IGNORE t1.* FROM t1, t2;
 
# Cleanup
DROP TABLE t0, t1, t2;

10.4 db537a83

mysqld: /data/src/10.4/sql/protocol.cc:617: void Protocol::end_statement(): Assertion `0' failed.
200513 19:41:16 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fd8385b3f12 in __GI___assert_fail (assertion=0x55fae0f01258 "0", file=0x55fae0f00f50 "/data/src/10.4/sql/protocol.cc", line=617, function=0x55fae0f018d0 <Protocol::end_statement()::__PRETTY_FUNCTION__> "void Protocol::end_statement()") at assert.c:101
#8  0x000055fae01101b4 in Protocol::end_statement (this=0x7fd8200010b8) at /data/src/10.4/sql/protocol.cc:617
#9  0x000055fae023514b in dispatch_command (command=COM_QUERY, thd=0x7fd820000af0, packet=0x7fd820136221 "DELETE IGNORE t1.* FROM t1, t2", packet_length=30, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:2433
#10 0x000055fae02318b7 in do_command (thd=0x7fd820000af0) at /data/src/10.4/sql/sql_parse.cc:1360
#11 0x000055fae03b9426 in do_handle_one_connection (connect=0x55fae4584cf0) at /data/src/10.4/sql/sql_connect.cc:1412
#12 0x000055fae03b9175 in handle_one_connection (arg=0x55fae4584cf0) at /data/src/10.4/sql/sql_connect.cc:1316
#13 0x000055fae0db91b1 in pfs_spawn_thread (arg=0x55fae45a0bf0) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#14 0x00007fd83a53c4a4 in start_thread (arg=0x7fd83275e700) at pthread_create.c:456
#15 0x00007fd838670d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.4-10.5. The test case is not applicable to 10.3.
Non-debug build doesn't crash. However, if I remove IGNORE from the last (multi-table) DELETE, both release and debug builds return

mysqltest: At line 14: query 'DELETE t1.* FROM t1, t2' failed: 1062: Duplicate entry '1' for key 'PRIMARY'

which is strange for DELETE.



 Comments   
Comment by Aleksey Midenkov [ 2021-12-23 ]

insert_portion_of_time() returns 121 but does not throw error message

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