Released on 21 Dec 2012
MySQL 5.1.67 Changelog

Bugs Fixed

  • Performance; InnoDB: The timing values for low-level InnoDB read operations were adjusted for better performance with fast storage devices, such as SSD. This enhancement primarily affects read operations for BLOB columns in compressed tables. (Bug #13702112, Bug #64258)

  • Incompatible Change: LAST_INSERT_ID(expr) did not work for expr values greater than the largest signed BIGINT value. Such arguments now are accepted, with some consequences for compatibility with previous versions:

    • LAST_INSERT_ID() now returns a BIGINT UNSIGNED value, not a BIGINT (signed) value.

    • LAST_INSERT_ID(expr) now returns an unsigned integer value, not a signed integer value.

    • For AUTO_INCREMENT columns, negative values are no longer supported.

    (Bug #20964, Bug #11745891)

  • InnoDB: An online DDL operation for an InnoDB table incorrectly reported an empty value ('') instead of the correct key value when it reported a duplicate key error for a unique index using an index prefix. (Bug #14729221)

  • InnoDB: If a CREATE TABLE statement failed due to a disk full error, some memory allocated during the operation was not freed properly. (Bug #14708715)

  • InnoDB: If the server crashed at the specific point when a change buffer entry was being merged into a buffer pool page, the transaction log and the change buffer were left in an inconsistent state. After a restart, MySQL could crash after reading the corresponding secondary index page. The problem was more likely to occur in MySQL 5.5 or later, where the original insert buffering mechanism was generalized to cover other operations. (Bug #14636528, Bug #66819, Bug #58571, Bug #61104, Bug #65443)

  • InnoDB: In rare circumstances, MySQL could apply InnoDB undo records out of order during a ROLLBACK of an operation that modified a BLOB column. This issue could cause an assertion error in debug builds:


    (Bug #13249921)

  • InnoDB: In debug builds, a mismatch in the InnoDB PAGE_FREE list would cause an assertion. (Bug #12701488)

  • Replication: Updates writing user variables whose values were never set on a slave while using --replicate-ignore-table could cause the slave to fail. (Bug #14597605)

    References: This bug was introduced by Bug #14275000.

  • Replication: Following an insert into a nontransactional table that failed due to insufficient disk space, the server did not properly clean up all pending events, leading to an assert or possibly to other errors. (Bug #11750014)

  • Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on replication slaves or cause failure of restore operations from binary log files. (Bug #66550, Bug #14548159, Bug #29422, Bug #11746883)

  • Within a stored procedure, executing a multiple-table DELETE statement that used a very long table alias could cause the server to exit. (Bug #15954896)

  • Very long database names in queries could cause the server to exit. (Bug #15912213, Bug #16900358)

  • Attempting to create an auto-increment column in an InnoDB table with a NULL type attribute could cause a serious error. (Bug #14758479)

  • A DELETE statement for an InnoDB table could write incorrect transaction metadata into a record, causing the server to halt with an error. To work around this issue, reduce the specified length of the primary key to less than 1K bytes. (Bug #14731482)

  • Repeated execution of a query containing a subquery that used MAX() could result in increasing memory consumption. (Bug #14683676)

  • USE dbname could fail with Unknown database when dbname contained multiple backtick (`) characters. (Bug #14645196)

  • SHOW PROFILE could be used to cause excessive server memory consumption. (Bug #14629232)

  • The thread cache implementation worked in LIFO rather than FIFO fashion and could result in a thread being denied service (although this was a remote possibility). (Bug #14621627)

  • CREATE USER and DROP USER could fail to flush the privileges, requiring FLUSH PRIVILEGES to be used explicitly. (Bug #13864642)

  • A memory leak could occur for queries containing a subquery that used GROUP BY on an outer column. (Bug #13724099)

  • A buffer too small error message from the myisamchk command referred to the myisam_sort_buffer_size configuration option, when it should have referred to sort_buffer_size.

    myisamchk now has a myisam_sort_buffer_size variable available as an alternative name to sort_buffer_size. myisam_sort_buffer_size is preferable to sort_buffer_size because its name corresponds to the myisam_sort_buffer_size server system variable that has a similar meaning. sort_buffer_size should be considered deprecated. (Bug #11754894, Bug #46578)

  • The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect. (Bug #11753779)

    References: See also Bug #38247, Bug #43006, Bug #45584, Bug #45606.

  • On Windows, the Perl version of mysql_install_db created system tables in the mysql database that were not populated properly. (Bug #65584, Bug #14181049)

  • mysqld_safe ignored the value of the UMASK environment variable, leading to behavior different from mysqld with respect to the access mode of created files. Now mysqld_safe (and mysqld_multi) attempt to approximate the same behavior as mysqld. (Bug #57406, Bug #11764559)

  • During optimization, ZEROFILL values may be converted to string constants. However, CASE expressions did not handle switching data types after the planning stage, leading to CASE finding a null pointer instead of its argument. (Bug #57135, Bug #11764313)