Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
10.1, 10.2, 10.3
Description
I am setting it to Minor, despite it being a corruption-looking error, because it is only reproducible on 10.1-10.3, apparently something has fixed it in 10.4+. Besides, it requires a non-default value of myisam_max_sort_file_size / aria_max_sort_file_size.
--source include/have_sequence.inc
|
|
CREATE TABLE t1 (a INT, b INT, KEY (a)) ENGINE=MyISAM; |
INSERT INTO t1 VALUES (8,8); |
INSERT INTO t1 SELECT seq, seq FROM seq_1_to_100000; |
|
SET GLOBAL myisam_max_sort_file_size= 1024*1024; |
ALTER TABLE t1 MODIFY b INT NOT NULL; |
|
--error ER_DUP_ENTRY
|
ALTER TABLE t1 ADD UNIQUE (b); |
|
# Cleanup
|
DROP TABLE t1; |
10.2 5f1ec5cb |
MariaDB [test]> ALTER TABLE t1 ADD UNIQUE (b); |
ERROR 1034 (HY000): Duplicate key 1 for record at 72 against new record at 0 |
There is indeed a duplicate key in the table, but it should be error 1062 - ER_DUP_ENTRY, not 1034 - ER_NOT_KEYFILE.
The printed duplicate key value is also wrong, possibly related to MDEV-23507.
The problem seems to be scalable, myisam_max_sort_file_size value required to reproduce it depends on the data volume.
Also reproducible with Aria:
--source include/have_sequence.inc
|
|
CREATE TABLE t1 (a INT, b INT, KEY (a)) ENGINE=Aria; |
INSERT INTO t1 VALUES (8,8); |
INSERT INTO t1 SELECT seq, seq FROM seq_1_to_100000; |
|
SET GLOBAL aria_max_sort_file_size= 0; |
ALTER TABLE t1 MODIFY b INT NOT NULL; |
|
--error ER_DUP_ENTRY
|
ALTER TABLE t1 ADD UNIQUE (b); |
|
# Cleanup
|
DROP TABLE t1; |