[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: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Description |
|
Starting MariaDB server version 10.4.18 some SQL updates on the transaction precise versioned table fail. 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:
|
| 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 ( |
| 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 |