Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4(EOL)
-
None
Description
Copying ALTER from ascii_general_ci to latin1_general_ci may fail in case of 8-bit characters:
DROP TABLE IF EXISTS t1; |
CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET ascii COLLATE ascii_general_ci, PRIMARY KEY(a)) ENGINE=InnoDB; |
INSERT INTO t1 VALUES ('a'),(0xC0),('b'); |
ALTER TABLE t1 ALGORITHM=COPY, MODIFY a VARCHAR(10) CHARACTER SET latin1 COLLATE latin1_general_ci; |
Instant ALTER performs such conversion silently, but then CHECK TABLE rerpots corrupted data:
ALTER TABLE t1 ALGORITHM=INSTANT, MODIFY a VARCHAR(10) CHARACTER SET latin1 COLLATE latin1_general_ci; |
CHECK TABLE t1; |
+---------+-------+----------+---------------------------------------------------+
|
| Table | Op | Msg_type | Msg_text |
|
+---------+-------+----------+---------------------------------------------------+
|
| test.t1 | check | Warning | InnoDB: The B-tree of index PRIMARY is corrupted. |
|
| test.t1 | check | error | Corrupt |
|
+---------+-------+----------+---------------------------------------------------+
|
Instant ALTER should be disallowed from ascii_general_ci to xxx_general_ci.
Attachments
Issue Links
- is caused by
-
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes
-
- Closed
-
- relates to
-
MDEV-19284 INSTANT ALTER with ucs2-to-utf16 conversion produces bad data
-
- Closed
-
-
MDEV-28323 Redundant Item_func_conv_charset on WHERE utf8mb4_field=utf8mb3_field
-
- Open
-
A similar problem is repeatable on alter from ascii_general_ci to utf8_general_ci.
ERROR 1366 (22007): Incorrect string value: '\xC0' for column `test`.`t1`.`a` at row 3
+--------+
| HEX(a) |
+--------+
| 61 |
| 62 |
| C0 |
+--------+
Notice, 0xC0 is a not well-formed utf8 string.