[MDEV-25644] UPDATE not working properly on transaction precise system versioned table Created: 2021-05-10  Updated: 2023-09-21  Resolved: 2023-07-20

Status: Closed
Project: MariaDB Server
Component/s: Versioned Tables
Affects Version/s: 10.4.18, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9
Fix Version/s: 10.4.31, 10.5.22, 10.6.15, 10.9.8, 10.10.6, 10.11.5, 11.0.3

Type: Bug Priority: Critical
Reporter: YURII KANTONISTOV Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: regression, trx-versioning
Environment:

CentOS 7


Attachments: Zip Archive v17_mariadb.zip     Zip Archive v17_v18_errorlog.zip     Zip Archive v18_mariadb.zip    
Issue Links:
Problem/Incident
is caused by MDEV-23446 UPDATE does not insert history row if... Closed
Relates
relates to MDEV-29813 REPLACE/IGNORE does not work with his... Closed
relates to MDEV-32221 SIGSEGV in ha_innobase::update_row, U... Open
relates to MDEV-29723 ROW START not always set correctly in... Open
relates to MDEV-30701 row_start not set properly when updat... Open

 Description   

Starting MariaDB server version 10.4.18 some SQL updates on the transaction precise versioned table fail.
100% reproducible with v10.4.18 and 10.4.19, see example below and detailed log in attachment v18_mariadb.log.

Attached also the same SQL commands executed against version 10.4.17 where everything works fine - v17_mariadb.log, as well as server errorlog - did not spot anything special in there.

Example:

create or replace table xxx (nid int, nstate int, ntype int, primary key(nid) );
 
alter table xxx add tx_start BIGINT UNSIGNED GENERATED ALWAYS AS ROW START INVISIBLE, add tx_end BIGINT UNSIGNED GENERATED ALWAYS AS ROW END INVISIBLE, add PERIOD FOR SYSTEM_TIME(tx_start, tx_end), add SYSTEM VERSIONING;
 
insert into xxx values (1,1,1);
Query OK, 1 row affected (0.003 sec)
 
select nid, nstate, tx_start, tx_end from xxx for system_time all where nid=1;
+-----+--------+----------+----------------------+
| nid | nstate | tx_start | tx_end               |
+-----+--------+----------+----------------------+
|   1 |      1 |   189558 | 18446744073709551615 |
+-----+--------+----------+----------------------+
1 row in set (0.000 sec)
 
start transaction;
Query OK, 0 rows affected (0.000 sec)
 
update xxx set nstate=nstate where nid=1;
Query OK, 0 rows affected (0.001 sec)
Rows matched: 1  Changed: 0  Warnings: 0
 
select nid, nstate, tx_start, tx_end from xxx for system_time all where nid=1;
+-----+--------+----------+----------------------+
| nid | nstate | tx_start | tx_end               |
+-----+--------+----------+----------------------+
|   1 |      1 |   189558 |               189561 |
|   1 |      1 |   189558 | 18446744073709551615 |
+-----+--------+----------+----------------------+
2 rows in set (0.001 sec)
 
update xxx set nstate=3 where nid=1;
ERROR 1761 (23000): Foreign key constraint for table 'xxx', record '1-18446744073709551615' would lead to a duplicate entry in table 'xxx', key 'PRIMARY'



 Comments   
Comment by Dennis DK [ 2022-10-05 ]

Haven't seen this on our own transaction precise tables, but stumbled over this report searching for something else, and the provided example still fails in 10.6.4.

That is...worrying. A critical regression being completely ignored (without even attempts at reproducing or understanding if/why this is a special case) for over a year even more so.

Comment by Dennis DK [ 2022-10-07 ]

I spoke too soon. I had another issue (MDEV-29723), that I thought was distinct from this one, but they seem related, as this one starts the same way: The first "non-update" (nstate=nstate) makes a weird change, where the new/updated row gets tx_start set to the original tx_start value, instead of the current transaction id. The old/previous row seems to updated correctly: starts at original value, ends at current tx id.

Well, after I while, we ran into the error... Just took the row being updated again.

I'll mark my issue as related. It may be closer to a duplicate, but it focuses more on the first weird update.

Comment by Alice Sherepa [ 2022-10-18 ]

I am sorry, but somehow the issue fell off the radar. It is caused by 9b38ed4c85bda25 commit (MDEV-23446), repeatable on 10.3-10.9

Comment by Aleksey Midenkov [ 2022-12-28 ]

Duplicate PK for history generation in same transaction should be ignored.

Comment by Aleksey Midenkov [ 2023-07-07 ]

Please review bb-10.4-midenok-MDEV-25644

Comment by Nikita Malyavin [ 2023-07-19 ]

53a177a44b710 is approved.

Comment by Aleksey Midenkov [ 2023-07-20 ]

10.4.31 10.5.22 10.6.15 10.9.8 10.10.6 10.11.5 11.0.3 11.1.2 11.2.1

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