[MDEV-22540] ER_DUP_ENTRY upon REPLACE or Assertion `transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table' failed Created: 2020-05-13  Updated: 2021-01-07  Resolved: 2021-01-07

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update, Versioned Tables
Affects Version/s: 10.3, 10.4, 10.5
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Nikita Malyavin
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates MDEV-17891 Assertion failures in select_insert::... Closed
Relates
relates to MDEV-22548 Assertion `0' failed in Protocol::end... Confirmed
relates to MDEV-23446 UPDATE does not insert history row if... Closed
relates to MDEV-16226 TRX_ID-based System Versioning refact... Stalled
relates to MDEV-24064 Utility columns for system-versioned ... Open
relates to MDEV-24451 Record retains new value on DML when ... Open

 Description   

Note: An assertion failure with the same text was filed as MDEV-17891, but it seems to be as far as similarities go: in this case, there is no full table, no abort_result_set, no partitioning. On the other hand, there is a very odd ER_DUP_ENTRY upon REPLACE. All in all, it might still be the same problem, but it seems unlikely.

SET TIMESTAMP=1589245268.41934;
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=MyISAM WITH SYSTEM VERSIONING;
INSERT INTO t1 VALUES (1),(2);
 
--connect (con1,localhost,root,,test)
SET TIMESTAMP=1589245268.52093;
REPLACE INTO t1 VALUES (1),(2);
 
--connection default
REPLACE INTO t1 VALUES (1),(2);
 
--connection con1
REPLACE INTO t1 VALUES (1),(2);

10.3 644d9f38 non-debug build

mysqltest: At line 14: query 'REPLACE INTO t1 VALUES (1),(2)' failed: 1062: Duplicate entry '1' for key 'PRIMARY'

10.3 644d9f38 debug

mysqld: /data/src/10.3/sql/sql_insert.cc:1200: bool mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool): Assertion `transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table' failed.
200513  4:03:27 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f8d9bdaff12 in __GI___assert_fail (assertion=0x558251cfa2e0 "transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table", file=0x558251cfa0f8 "/data/src/10.3/sql/sql_insert.cc", line=1200, function=0x558251cfadc0 <mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool)::__PRETTY_FUNCTION__> "bool mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool)") at assert.c:101
#8  0x000055825105f5d6 in mysql_insert (thd=0x7f8d78000af0, table_list=0x7f8d78011540, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_REPLACE, ignore=false) at /data/src/10.3/sql/sql_insert.cc:1199
#9  0x00005582510a2dac in mysql_execute_command (thd=0x7f8d78000af0) at /data/src/10.3/sql/sql_parse.cc:4454
#10 0x00005582510ae8d1 in mysql_parse (thd=0x7f8d78000af0, rawbuf=0x7f8d78011458 "REPLACE INTO t1 VALUES (1),(2)", length=30, parser_state=0x7f8d95f635e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7817
#11 0x000055825109b13f in dispatch_command (command=COM_QUERY, thd=0x7f8d78000af0, packet=0x7f8d78008c71 "REPLACE INTO t1 VALUES (1),(2)", packet_length=30, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
#12 0x0000558251099a57 in do_command (thd=0x7f8d78000af0) at /data/src/10.3/sql/sql_parse.cc:1401
#13 0x0000558251211c23 in do_handle_one_connection (connect=0x55825403de20) at /data/src/10.3/sql/sql_connect.cc:1403
#14 0x0000558251211985 in handle_one_connection (arg=0x55825403de20) at /data/src/10.3/sql/sql_connect.cc:1308
#15 0x0000558251bc4c70 in pfs_spawn_thread (arg=0x558253f8a4e0) at /data/src/10.3/storage/perfschema/pfs.cc:1869
#16 0x00007f8d9dd384a4 in start_thread (arg=0x7f8d95f64700) at pthread_create.c:456
#17 0x00007f8d9be6cd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.3-10.5.



 Comments   
Comment by Nikita Malyavin [ 2020-10-25 ]

The assertion failure should be fixed by MDEV-17891 fix (https://github.com/MariaDB/server/commit/688b9de0fedfcf13c4d33e7aa98e03e6e37cb0fb)

Though I am not sure about ER_DUP_ENTRY – it obviously fails because the same history row is inserted twice (why do you ever need two connections here, I don't know) because of the frozen timestamp.

Maybe we should silently skip ER_DUP_ENTRY when inserting history row, I don't know. I think you can achieve the same results with UPDATE/DELETE, too.

Isn't this `timestamp` feature for debugging/hacks purposes only?

Comment by Aleksey Midenkov [ 2020-10-30 ]

ER_DUP_ENTRY is expected behavior now as we must have history on every successful UPDATE (MDEV-23446). Better solution would be to have HISTORY_ID system-invisible column, but that new feature will not go to stable branch.

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