Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not a Bug
    • 10.4(EOL), 10.5, 10.6, 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL), 11.3(EOL), 11.4
    • N/A
    • debian 12
      11.2.2-MariaDB-1:11.2.2+maria~deb12

    Description

      CREATE TABLE `test` (
      `id` int(11) NOT NULL,
      `txt` varchar(255) NOT NULL
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

      INSERT INTO `test` (`id`, `txt`) VALUES (1, 'test');

      Doing

      INSERT INTO `test` (`id`, `txt`) VALUES (2, 'test ');

      Throws a duplicate index error because the txt value is trimed.

      Attachments

        Issue Links

          Activity

            There is no unique index defined in the Description nor in test.sql. I can reproduce a duplicate key error as follows:

            --source include/have_innodb.inc
            CREATE TABLE test (
              id int PRIMARY KEY, txt varchar(255) NOT NULL UNIQUE
            ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
            INSERT INTO test VALUES (1, 'test'),(2, 'test ');
            DROP TABLE test;
            

            10.6 ccb7a1e9a15e6a47aba97f9bdbfab2e4bf64c447

            mysqltest: At line 5: query 'INSERT INTO test VALUES (1, 'test'),(2, 'test ')' failed: ER_DUP_ENTRY (1062): Duplicate entry 'test ' for key 'txt'
            

            10.4 a618ff2b1c3980d20d258d7da0afb1e7b7ec1516

            mysqltest: At line 5: query 'INSERT INTO test VALUES (1, 'test'),(2, 'test ')' failed: 1062: Duplicate entry 'test ' for key 'txt'
            

            If I omit the first row, SELECT LENGTH(txt) FROM test will display 5, so the text is not being trimmed. I can also see that cmp_dtuple_rec() is being invoked during the INSERT, comparing the 4-byte string in the buffer page to the 5-byte string that is being inserted.

            I could also reproduce this with utf8mb3_general_ci and latin1_swedish_ci. For the latter, my_charset_latin1.strnncollsp() or my_strnncollsp_simple() would be returning 0, claiming that the strings are identical. As far as I can tell, if there is a bug, it is in that function.

            I did not test an old enough version to check how this worked before MDEV-25904 or MDEV-9711, but I suspect that this was broken by those changes. I remember that MySQL 5.0.3 introduced a "true VARCHAR" data type that would take the length of trailing spaces into account. We already had another report MDEV-30095 about unexpected duplicate key errors.

            I can imagine that fixing this bug may make some indexes appear as corrupted, because the fix would require some changes to the collation rules.

            marko Marko Mäkelä added a comment - There is no unique index defined in the Description nor in test.sql . I can reproduce a duplicate key error as follows: --source include/have_innodb.inc CREATE TABLE test ( id int PRIMARY KEY , txt varchar (255) NOT NULL UNIQUE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE =utf8mb4_general_ci; INSERT INTO test VALUES (1, 'test' ),(2, 'test ' ); DROP TABLE test; 10.6 ccb7a1e9a15e6a47aba97f9bdbfab2e4bf64c447 mysqltest: At line 5: query 'INSERT INTO test VALUES (1, 'test'),(2, 'test ')' failed: ER_DUP_ENTRY (1062): Duplicate entry 'test ' for key 'txt' 10.4 a618ff2b1c3980d20d258d7da0afb1e7b7ec1516 mysqltest: At line 5: query 'INSERT INTO test VALUES (1, 'test'),(2, 'test ')' failed: 1062: Duplicate entry 'test ' for key 'txt' If I omit the first row, SELECT LENGTH(txt) FROM test will display 5, so the text is not being trimmed. I can also see that cmp_dtuple_rec() is being invoked during the INSERT , comparing the 4-byte string in the buffer page to the 5-byte string that is being inserted. I could also reproduce this with utf8mb3_general_ci and latin1_swedish_ci . For the latter, my_charset_latin1.strnncollsp() or my_strnncollsp_simple() would be returning 0, claiming that the strings are identical. As far as I can tell, if there is a bug, it is in that function. I did not test an old enough version to check how this worked before MDEV-25904 or MDEV-9711 , but I suspect that this was broken by those changes. I remember that MySQL 5.0.3 introduced a "true VARCHAR " data type that would take the length of trailing spaces into account. We already had another report MDEV-30095 about unexpected duplicate key errors. I can imagine that fixing this bug may make some indexes appear as corrupted, because the fix would require some changes to the collation rules.

            Sorry, I did not realize that MDEV-9711 had been implemented to address exactly this scenario. There will be no duplicate key reported for the following:

            --source include/have_innodb.inc
            CREATE TABLE test (
              id int PRIMARY KEY, txt varchar(255) NOT NULL UNIQUE
            ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_nopad_ci;
            INSERT INTO test VALUES (1, 'test'),(2, 'test ');
            DROP TABLE test;
            

            Similar for utf8mb3_general_nopad_ci and latin1_swedish_nopad_ci.

            marko Marko Mäkelä added a comment - Sorry, I did not realize that MDEV-9711 had been implemented to address exactly this scenario. There will be no duplicate key reported for the following: --source include/have_innodb.inc CREATE TABLE test ( id int PRIMARY KEY , txt varchar (255) NOT NULL UNIQUE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE =utf8mb4_general_nopad_ci; INSERT INTO test VALUES (1, 'test' ),(2, 'test ' ); DROP TABLE test; Similar for utf8mb3_general_nopad_ci and latin1_swedish_nopad_ci .

            People

              marko Marko Mäkelä
              gothge Jorg Singendonk
              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.