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