Skip navigation links

Additional languages
B.1.8 Changes in MySQL 4.1.17 (Not released) »
Section Navigation      [Toggle]

B.1.7. Changes in MySQL 4.1.18 (27 January 2006)

End of Product Lifecycle. Active development and support for MySQL database server versions 3.23, 4.0, and 4.1 has ended. However, for MySQL 4.0 and 4.1, there is still extended support available. For details, see http://www.mysql.com/company/legal/lifecycle/#calendar. According to the MySQL Lifecycle Policy (see http://www.mysql.com/company/legal/lifecycle/#policy), only Security and Severity Level 1 issues will still be fixed for MySQL 4.0 and 4.1. Please consider upgrading to a recent version (MySQL 5.0 or 5.1).

Functionality added or changed:

  • MySQL Cluster: More descriptive warnings are now issued when inappropriate logging parameters are set in config.ini. (Formerly, the warning issued was simply Could not add logfile destination.) (Bug#11331)

  • libmysqlclient now uses versioned symbols with GNU ld. (Bug#3074)

Bugs fixed:

  • UPDATE statement crashed multi-byte character set FULLTEXT index if update value was almost identical to initial value only differing in some spaces being changed to  . (Bug#16489)

  • The --replicate-do and --replicate-ignore options were not being enforced on multiple-table statements. (Bug#16487, Bug#15699)

  • Single table UPDATE statements without ORDER BY clauses which updated the same indexed column that was being filtered on were optimized with a full index scan instead of a more appropriate index range scan. (Bug#15935)

  • STR_TO_DATE(1,NULL) caused a server crash. (Bug#15828, CVE-2006-3081)

  • Test suite func_math test returned warnings when server not compiled with InnoDB support. (Bug#15429)

  • RPM packages had an incorrect zlib dependency. (Bug#15223)

  • Running out of diskspace in the location specified by the tmpdir option resulted in incorrect error message. (Bug#14634)

  • The MBROverlaps GIS function returned incorrect results. (Bug#14320)

  • The length of a VARCHAR() column that used the utf8 character set would increase each time the table was re-created in a stored procedure or prepared statement, eventually causing the CREATE TABLE statement to fail. (Bug#13134)

  • A prepared statement created from a SELECT ... LIKE query (such as PREPARE stmt1 FROM 'SELECT col_1 FROM tedd_test WHERE col_1 LIKE ?';) would begin to produce erratic results after being executed repeatedly numerous (thousands) of times. (Bug#12734)

  • A CREATE TABLE ... SELECT ... on an equation involving DOUBLE values could result in the table being created with columns too small to hold the equation result. (Bug#9855)