Bug #9085 4.0 tables containing embedded string values < 32 corrupted in 4.1

• Submitted: 10 Mar 2005 2:55
• Modified: 10 Mar 2005 19:44
• Reporter: Dean Ellis
• Status: Not a Bug
• Category: MySQL Server: MyISAM storage engine
• Severity: S1 (Critical)
• Version: 4.1.11
• CPU Architecture: Any

[10 Mar 2005 2:55] Dean Ellis

Description:
Tables created in 4.0, which contain indexed columns that have embedded (non-trailing) values < ASCII(32) are corrupt in MySQL 4.1 (keys out of order, etc).

Identical behavior/symptoms/fix as with trailing values < 32.

How to repeat:
In 4.0:

CREATE TABLE t1 ( a VARCHAR(100), INDEX (a) );
INSERT INTO t1 VALUES ('A'),('A\tB');
FLUSH TABLES:

Check table with MySQL 4.1's myisamchk, or with 4.1's CHECK TABLE.

Suggested fix:
n/a

[10 Mar 2005 9:15] Sergei Golubchik

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.mysql.com/documentation/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Additional info:

It's documented in the "Upgrading from Version 4.0 to 4.1" section:

   * *Incompatible change:* There are conditions under which you should
     rebuild tables.  In general, to rebuild a table, dump it with
     `mysqldump' and reload the dump file.  Some items in the following
     list indicate alternatives means for rebuilding.

        - Starting from MySQL 4.1.3, `InnoDB' uses the same character
          set comparison functions as MySQL for non-`latin1_swedish_ci'
          character strings that are not `BINARY'.  This changes the
          sorting order of space and characters with a code < ASCII(32)
          in those character sets.  For `latin1_swedish_ci' character
          strings and `BINARY' strings, `InnoDB' uses its own
          pad-spaces-at-end comparison method, which stays unchanged.
          If you have an `InnoDB' table created with MySQL 4.1.2 or
          earlier, with an index on a non-`latin1' character set (in
          the case of 4.1.0 and 4.1.1, with any character set) and the
          table contains any `CHAR'/`VARCHAR'/or `TEXT' columns that are
          not `BINARY' but may contain characters with a code <
          ASCII(32), then you should do `ALTER TABLE' or `OPTIMIZE
          TABLE' on it to regenerate the index, after upgrading to
          MySQL 4.1.3 or later.  Also, `MyISAM' tables have to be
          rebuilt or repaired in these cases.