Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-25644

UPDATE not working properly on transaction precise system versioned table

Details

    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'
      

      Attachments

        Issue Links

          Activity

            losd Dennis DK added a comment -

            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.

            losd Dennis DK added a comment - 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.
            losd Dennis DK added a comment -

            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.

            losd Dennis DK added a comment - 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.
            alice Alice Sherepa added a comment -

            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

            alice Alice Sherepa added a comment - 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

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

            midenok Aleksey Midenkov added a comment - Duplicate PK for history generation in same transaction should be ignored.
            midenok Aleksey Midenkov added a comment - Please review bb-10.4-midenok-MDEV-25644

            53a177a44b710 is approved.

            nikitamalyavin Nikita Malyavin added a comment - 53a177a44b710 is approved.

            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

            midenok Aleksey Midenkov added a comment - 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

            People

              midenok Aleksey Midenkov
              ykantoni YURII KANTONISTOV
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.