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

System versioning setting to allow history modification

Details

    Description

      Add a session server variable @@system_versioning_insert_history which allows to use ROW_START and ROW_END columns in the INSERT (unless they are normal visible (in SELECT *) fields, they have to be explicitly specified in INSERT as any invisible fields are). And if @@secure_timestamp allows the current user to modify @@timestamp then he should be able to insert directly into ROW_START/ROW_END columns.

      The use case of this is to be able to dump the history with mysqldump and to load it back later (MDEV-16029). It provides a convenient way to have a row in the system versioned table with row_start=A and row_end=B. Without @@system_versioning_insert_history it can be achieved with

      set @@timestamp=A;
      insert t1 values (...);
      set @@timestamp=B;
      delete from t1 where ... -- a condition to match the row that was just inserted
      

      So this new feature does not provide any new functionality, but allows to load the history dump much faster than with timestamp manipulations as above. In particular it does not allow to do anything that wasn't possible to do before, it requires exactly the same set of privileges as the snippet above, and is subject to the same set of restrictions.

      Attachments

        Issue Links

          Activity

            Fixed. It should not go into Item_field::fix_fields() because there is no explicit field list (so no Item_field). It uses different fill_record() for implicit field list, that's normal.

            midenok Aleksey Midenkov added a comment - Fixed. It should not go into Item_field::fix_fields() because there is no explicit field list (so no Item_field). It uses different fill_record() for implicit field list, that's normal.

            I wanted to split THD::vers_insert_history(Field *) into Field::vers_insert_history(THD *) and THD::vers_insert_history(). But they both cannot be inline (or it sort of hard to rule out without inline files) because Field::vers_insert_history(THD *) must call THD::vers_insert_history() but sql_class.h is not included into field.h. serg, I remember about your inline request.

            midenok Aleksey Midenkov added a comment - I wanted to split THD::vers_insert_history(Field *) into Field::vers_insert_history(THD *) and THD::vers_insert_history() . But they both cannot be inline (or it sort of hard to rule out without inline files) because Field::vers_insert_history(THD *) must call THD::vers_insert_history() but sql_class.h is not included into field.h . serg , I remember about your inline request.

            midenok, you haven't fixed the issue yet. You don't have the test case for it. If you do

            -insert into t3(z, row_start, row_end) values (5, '1980-01-01 00:00:00', '1980-01-01 00:00:01');
            +insert into t3 values (5, '1980-01-01 00:00:00', '1980-01-01 00:00:01');
            

            you'll see that values are ignored

            serg Sergei Golubchik added a comment - midenok , you haven't fixed the issue yet. You don't have the test case for it. If you do -insert into t3(z, row_start, row_end) values (5, '1980-01-01 00:00:00', '1980-01-01 00:00:01'); +insert into t3 values (5, '1980-01-01 00:00:00', '1980-01-01 00:00:01'); you'll see that values are ignored

            pushed into bb-10.11-MDEV-16546

            serg Sergei Golubchik added a comment - pushed into bb-10.11- MDEV-16546

            I have no objections against pushing bb-10.11-MDEV-16546 as of 87fca0525 into 10.11 branch and releasing it with 10.11.1.

            Some notes in no particular order (greenman FYI):

            • the final implementation allows INSERT, CREATE .. INSERT, and LOAD; does not allow REPLACE, LOAD .. REPLACE, UPDATE, INSERT .. ON DUPLICATE KEY UPDATE
            • in addition to sufficient permissions to change the timestamp, the user performing the operation naturally also needs standard grants for inserting into the table;
            • the variable is already in the KB, but the description needs to indicate that it only applies to timestamp-based versioning;
            • while inserting history into a versioned table with limit-based partitioning, the user must be aware of MDEV-29674, all injected historical rows are inserted into the first partition. It may be fixed in future;
            • in general, functionality is mainly aimed for re-loading the real history by the means of mysqldump / restoration. While arbitrary history inserting also works, the effect may be not quite what the user expects to achieve.
            • see also notes in MDEV-16029.
            elenst Elena Stepanova added a comment - I have no objections against pushing bb-10.11- MDEV-16546 as of 87fca0525 into 10.11 branch and releasing it with 10.11.1. Some notes in no particular order ( greenman FYI): the final implementation allows INSERT , CREATE .. INSERT , and LOAD ; does not allow REPLACE , LOAD .. REPLACE , UPDATE , INSERT .. ON DUPLICATE KEY UPDATE in addition to sufficient permissions to change the timestamp, the user performing the operation naturally also needs standard grants for inserting into the table; the variable is already in the KB , but the description needs to indicate that it only applies to timestamp-based versioning; while inserting history into a versioned table with limit-based partitioning, the user must be aware of MDEV-29674 , all injected historical rows are inserted into the first partition. It may be fixed in future; in general, functionality is mainly aimed for re-loading the real history by the means of mysqldump / restoration. While arbitrary history inserting also works, the effect may be not quite what the user expects to achieve. see also notes in MDEV-16029 .

            People

              serg Sergei Golubchik
              midenok Aleksey Midenkov
              Votes:
              8 Vote for this issue
              Watchers:
              17 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.