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.
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
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-25904orMDEV-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.