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

            elenst Elena Stepanova created issue -
            elenst Elena Stepanova made changes -
            Field Original Value New Value
            elenst Elena Stepanova made changes -

            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?
            elenst Elena Stepanova made changes -
            Assignee Elena Stepanova [ elenst ] Sergei Golubchik [ serg ]
            elenst Elena Stepanova made changes -
            serg Sergei Golubchik made changes -
            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-553 - 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-553).

            Result files need to be updated. For MDEV_553, also test files which expect a different error code need to be modified.
            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.
            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
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Michael Widenius [ monty ]
            serg Sergei Golubchik made changes -

            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
            serg Sergei Golubchik made changes -
            Assignee Michael Widenius [ monty ] Elena Stepanova [ elenst ]
            elenst Elena Stepanova made changes -
            Status Open [ 1 ] In Progress [ 3 ]

            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.
            elenst Elena Stepanova made changes -
            Assignee Elena Stepanova [ elenst ] Sergei Golubchik [ serg ]
            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.
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Elena Stepanova [ elenst ]
            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
            elenst Elena Stepanova made changes -
            Status In Progress [ 3 ] Open [ 1 ]

            pushed into 10.0-base

            elenst Elena Stepanova added a comment - pushed into 10.0-base
            elenst Elena Stepanova made changes -
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Closed [ 6 ]
            serg Sergei Golubchik made changes -
            Workflow defaullt [ 25756 ] MariaDB v2 [ 45346 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Workflow MariaDB v2 [ 45346 ] MariaDB v3 [ 66009 ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 66009 ] MariaDB v4 [ 132047 ]

            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.