MySQL

4.0.23

Released on 18 Dec 2004
MySQL 4.0.23 Changelog

End of Product Lifecycle.Ā Active development and support for MySQL Database Server versions 3.23, 4.0, and 4.1 has ended. For details, see http://www.mysql.com/about/legal/lifecycle/#calendar. Please consider upgrading to a recent version. Further updates to the content of this manual will be minimal. All formats of this manual will continue to be available until 31 Dec 2010.

Note

Due to a libtool-related bug in the source distribution, the creation of shared libmysqlclient libraries was not possible (the resulting files were missing the .so file name extension). The file ltmain.sh was updated to fix this problem and the resulting source distribution was released as mysql-4.0.23a.tar.gz. This modification did not affect the binary packages. (Bug #7401)

Functionality added or changed:

  • Added --hex-blob option to mysqldump for dumping binary string columns using hexadecimal notation.

  • Added mysql_hex_string() C API function that hex-encodes a string.

  • InnoDB: Do not periodically write SHOW INNODB STATUS information to a temporary file unless the configuration option innodb-status-file = 1 is set.

  • InnoDB: Made the foreign key parser better aware of quotation marks. (Bug #6340)

  • mysqlbinlog now prints an informative commented line (thread id, timestamp, server id, and so forth) before each LOAD DATA INFILE, like it does for other queries; unless --short-form is used.

Bugs fixed:

  • A multiple-table DELETE could cause MySQL to crash when using InnoDB tables. (Bug #5837, Bug #6378)

  • Corrected accounts in the mysql.user table in Windows distributions that had been created with a Host value of build rather than %. (Bug #6000)

  • Prevent adding CREATE TABLE .. SELECT query to the binary log when the insertion of new records partially failed. (Bug #6682)

  • Fixed bug which caused FROM_UNIXTIME() function to return wrong result if the argument was too big. (Bug #6439)

  • Fixed bug which caused MySQL server to store wrong values in TIMESTAMP columns and give wrong results for UNIX_TIMESTAMP() function if it was run in time zone with leap seconds. (Bug #6387)

  • InnoDB: Fixed a bug in LOAD DATA INFILEā€¦REPLACE printing duplicate key error when executing the same load query several times. (Bug #5835)

  • InnoDB: Refuse to open new-style tables created with MySQL 5.0.3 or later. (Bug #7089)

  • InnoDB: Do not call rewind() when displaying SHOW INNODB STATUS information on stderr.

  • InnoDB: If one used INSERT IGNORE to insert several rows at a time, and the first inserts were ignored because of a duplicate key collision, then InnoDB in a replication slave assigned AUTO_INCREMENT values 1 bigger than in the master. This broke the MySQL replication. (Bug #6287)

  • InnoDB: Fix two hangs: FOREIGN KEY constraints treated table and database names as case-insensitive. RENAME TABLE t TO T would hang in an endless loop if t had a foreign key constraint defined on it. Fix also a hang over the dictionary mutex that would occur if one tried in ALTER TABLE or RENAME TABLE to create a foreign key constraint name that collided with another existing name. (Bug #3478)

  • InnoDB: Treat character 0xA0 as space in InnoDB's FOREIGN KEY parser if MySQL treats it as space in the default charset. EMS MySQL Manager inserts character 0xA0 after the table name in an ALTER, which confused InnoDB's parser.

  • Fixed a bug which caused a crash when only the slave I/O thread was stopped and restarted. (Bug #6148)

  • If a connection had an open transaction but had done no updates to transactional tables (for example, if had just done a SELECT FOR UPDATE then executed a nontransactional update, that update automatically committed the transaction (thus releasing InnoDB's row-level locks etc). (Bug #5714)

  • If a connection was interrupted by a network error and did a rollback, the network error code got stored into the BEGIN and ROLLBACK binary log events; that caused superfluous slave stops. (Bug #6522)

  • A sequence of BEGIN (or SET autocommit = 0), FLUSH TABLES WITH READ LOCK, transactional update, COMMIT, FLUSH TABLES WITH READ LOCK could hang the connection forever and possibly the MySQL server itself. This happened for example when running the innobackup script several times. (Bug #6732)