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

engines/* and storage_engine tests and result files went out of sync with current MariaDB code

Details

    • Task
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • 10.0.2, 5.5.29
    • None
    • None

    Description

      storage_engine tests and upstream engines/* suites went out of sync with current MariaDB code. Reasons:

      • as of 5.5.27, YEAR(2) is deprecated, hence the new warning;
      • MDEV-533 - different error code/message on out-of-range auto-increment;
      • INSERT IGNORE now produces a warning if a duplicate key was encountered (change pushed along with MDEV-533).

      Result files need to be updated. For MDEV-533, also test files which expect a different error code need to be modified.

      Attachments

        Issue Links

          Activity

            Hi Sergei,

            Here is the patch: http://bazaar.launchpad.net/~elenst/maria/5.5-engines-tests/revision/3605

            No harm is done, it's only tests and results in suites which are not a part of the standard set. Is it okay to push into 5.5?

            elenst Elena Stepanova added a comment - Hi Sergei, Here is the patch: http://bazaar.launchpad.net/~elenst/maria/5.5-engines-tests/revision/3605 No harm is done, it's only tests and results in suites which are not a part of the standard set. Is it okay to push into 5.5?
            serg Sergei Golubchik added a comment - - edited

            Hi, Elena!

            The only questionable change is in the file
            mysql-test/suite/storage_engine/autoinc_vars.result

            monty, is that change ok?

            Regards,
            Sergei

            serg Sergei Golubchik added a comment - - edited Hi, Elena! The only questionable change is in the file mysql-test/suite/storage_engine/autoinc_vars.result monty , is that change ok? Regards, Sergei

            For Monty's reference, I'll put the change and the context here.

            =====================================
            The change:

            === modified file 'mysql-test/suite/storage_engine/autoinc_vars.result'
            — mysql-test/suite/storage_engine/autoinc_vars.result 2012-07-16 02:17:56 +0000
            +++ mysql-test/suite/storage_engine/autoinc_vars.result 2012-12-28 13:02:33 +0000
            @@ -44,12 +44,10 @@
            SET auto_increment_offset = 300;
            CREATE TABLE t1 (a TINYINT <CUSTOM_COL_OPTIONS> AUTO_INCREMENT, <CUSTOM_INDEX>(a)) ENGINE=<STORAGE_ENGINE> <CUSTOM_TABLE_OPTIONS>;
            INSERT INTO t1 (a) VALUES (NULL);
            -Warnings:
            -Warning 1264 Out of range value for column 'a' at row 1
            +ERROR 22003: Out of range value for column 'a' at row 1
            SELECT LAST_INSERT_ID();
            LAST_INSERT_ID()
            -127
            +850
            SELECT * FROM t1;
            a
            -127
            DROP TABLE t1;

            =====================================
            Context:

            This part of the test does the following:

            SET auto_increment_increment = 500;
            SET auto_increment_offset = 300;
            CREATE TABLE t1 (a TINYINT AUTO_INCREMENT PRIMARY KEY);
            INSERT INTO t1 (a) VALUES (NULL);

            Thus, the inserted value should have been 300, but TINYINT doesn't allow for that. So, earlier the value was truncated with the warning and the max possible value was inserted (and hence LAST_INSERT_ID was updated), while now it throws an error instead, nothing is inserted (and LAST_INSERT_ID remains old, 850 is the value from the previous part of the test)

            elenst Elena Stepanova added a comment - For Monty's reference, I'll put the change and the context here. ===================================== The change: === modified file 'mysql-test/suite/storage_engine/autoinc_vars.result' — mysql-test/suite/storage_engine/autoinc_vars.result 2012-07-16 02:17:56 +0000 +++ mysql-test/suite/storage_engine/autoinc_vars.result 2012-12-28 13:02:33 +0000 @@ -44,12 +44,10 @@ SET auto_increment_offset = 300; CREATE TABLE t1 (a TINYINT <CUSTOM_COL_OPTIONS> AUTO_INCREMENT, <CUSTOM_INDEX>(a)) ENGINE=<STORAGE_ENGINE> <CUSTOM_TABLE_OPTIONS>; INSERT INTO t1 (a) VALUES (NULL); -Warnings: -Warning 1264 Out of range value for column 'a' at row 1 +ERROR 22003: Out of range value for column 'a' at row 1 SELECT LAST_INSERT_ID(); LAST_INSERT_ID() -127 +850 SELECT * FROM t1; a -127 DROP TABLE t1; ===================================== Context: This part of the test does the following: SET auto_increment_increment = 500; SET auto_increment_offset = 300; CREATE TABLE t1 (a TINYINT AUTO_INCREMENT PRIMARY KEY); INSERT INTO t1 (a) VALUES (NULL); Thus, the inserted value should have been 300, but TINYINT doesn't allow for that. So, earlier the value was truncated with the warning and the max possible value was inserted (and hence LAST_INSERT_ID was updated), while now it throws an error instead, nothing is inserted (and LAST_INSERT_ID remains old, 850 is the value from the previous part of the test)

            Yes, this is ok. There is also a test case for this behavior change in t/auto_increment.test

            monty Michael Widenius added a comment - Yes, this is ok. There is also a test case for this behavior change in t/auto_increment.test

            Elena, please feel free to push

            serg Sergei Golubchik added a comment - Elena, please feel free to push

            pushed to maria/5.5.
            Not closing because 10.0 might require more changes, still need to check it.

            elenst Elena Stepanova added a comment - pushed to maria/5.5. Not closing because 10.0 might require more changes, still need to check it.

            Hi Sergei,

            Here is the 10.0 part (on top of the previous change):
            http://bazaar.launchpad.net/~elenst/maria/10.0-base-mdev3990/revision/3468

            I listed sources of the differences, as much as I could identify them, in the commit comment.

            elenst Elena Stepanova added a comment - Hi Sergei, Here is the 10.0 part (on top of the previous change): http://bazaar.launchpad.net/~elenst/maria/10.0-base-mdev3990/revision/3468 I listed sources of the differences, as much as I could identify them, in the commit comment.
            serg Sergei Golubchik added a comment - - edited

            Everything, but the insert_time.result is certainly ok.
            changes in the insert_time.result look plausible too, but I didn't track every 00:00:00 change back to its origin, incorrectly formatted time.

            serg Sergei Golubchik added a comment - - edited Everything, but the insert_time.result is certainly ok. changes in the insert_time.result look plausible too, but I didn't track every 00:00:00 change back to its origin, incorrectly formatted time.
            elenst Elena Stepanova added a comment - - edited

            What I did was take this test:

            create table t1 (c1 time);
            insert into t1 values ('00:00:00');
            select * from t1 where c1 >='12colon34colon56';
            c1
            00:00:00
            Warnings:
            Warning 1292 Truncated incorrect time value: '12colon34colon56'

            And ran it before and after MDEV-457 fix. Before it was returning the value, after it wasn't – so I figured it's related to that change. MySQL doesn't return a value either, so at least it's consistent.

            My understanding is this:
            '12colon34colon56' is truncated to '12' and considered to be '00:00:12';
            so, everything less than that (up to and including '00:00:11' in that test) is filtered out, and the rest is included in the result set.

            elenst Elena Stepanova added a comment - - edited What I did was take this test: create table t1 (c1 time); insert into t1 values ('00:00:00'); select * from t1 where c1 >='12colon34colon56'; c1 00:00:00 Warnings: Warning 1292 Truncated incorrect time value: '12colon34colon56' And ran it before and after MDEV-457 fix. Before it was returning the value, after it wasn't – so I figured it's related to that change. MySQL doesn't return a value either, so at least it's consistent. My understanding is this: '12colon34colon56' is truncated to '12' and considered to be '00:00:12'; so, everything less than that (up to and including '00:00:11' in that test) is filtered out, and the rest is included in the result set.

            ok to push in 10.0-base

            serg Sergei Golubchik added a comment - ok to push in 10.0-base

            pushed into 10.0-base

            elenst Elena Stepanova added a comment - pushed into 10.0-base

            People

              elenst Elena Stepanova
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.