Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4(EOL), 10.5, 10.6, 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL)
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.
Attachments
Issue Links
- relates to
-
MDEV-25021 Assertion `0' failed in Protocol::end_statement upon multi-table delete with foreign key
- Confirmed
-
MDEV-22540 ER_DUP_ENTRY upon REPLACE or Assertion `transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table' failed
- Closed