Documentation Home
MySQL 5.1 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 2.1Mb
PDF (A4) - 2.1Mb
EPUB - 0.5Mb

MySQL 5.1 Release Notes  /  Changes in MySQL 5.1.51 (2010-09-10)

Changes in MySQL 5.1.51 (2010-09-10)

InnoDB Plugin Notes

  • InnoDB Plugin has been upgraded to version 1.0.12. This version is considered of General Availability (GA) quality.

    In this release, the InnoDB Plugin is included in source and binary distributions, except RHEL3, RHEL4, SuSE 9 (x86, x86_64, ia64), and generic Linux RPM packages. It also does not work for FreeBSD 6 and HP-UX or for Linux on generic ia64.

Functionality Added or Changed

  • Incompatible Change: Previously, if you flushed the logs using FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the error log to a file (for example, if it was started with the --log-error option), it renamed the current log file with the suffix -old, then created a new empty log file. This had the problem that a second log-flushing operation thus caused the original error log file to be lost unless you saved it under a different name. For example, you could use the following commands to save the file:

    shell> mysqladmin flush-logs
    shell> mv host_name.err-old backup-directory

    To avoid the preceding file-loss problem, renaming no longer occurs. The server merely closes and reopens the log file. To rename the file, you can do so manually before flushing. Then flushing the logs reopens a new file with the original file name. For example, you can rename the file and create a new one using the following commands:

    shell> mv host_name.err host_name.err-old
    shell> mysqladmin flush-logs
    shell> mv host_name.err-old backup-directory

    (Bug #29751)

    References: See also Bug #56821.

Bugs Fixed

  • Security Fix: During evaluation of arguments to extreme-value functions such as LEAST() and GREATEST(), type errors did not propagate properly, causing the server to crash. (Bug #55826, CVE-2010-3833)

  • Security Fix: The server could crash after materializing a derived table that required a temporary table for grouping. (Bug #55568, CVE-2010-3834)

  • Security Fix: A user-variable assignment expression that is evaluated in a logical expression context can be precalculated in a temporary table for GROUP BY. However, when the expression value is used after creation of the temporary table, it was re-evaluated, not read from the table, and a server crash resulted. (Bug #55564, CVE-2010-3835)

  • Security Fix: The CONVERT_TZ() function crashed the server when the timezone argument was an empty SET column value. (Bug #55424)

  • Security Fix: Pre-evaluation of LIKE predicates during view preparation could cause a server crash. (Bug #54568, Bug #11762026, CVE-2010-3836)

  • Security Fix: GROUP_CONCAT() and WITH ROLLUP together could cause a server crash. (Bug #54476, CVE-2010-3837)

  • Security Fix: Queries could cause a server crash if the GREATEST() or LEAST() function had a mixed list of numeric and LONGBLOB arguments, and the result of such a function was processed using an intermediate temporary table. (Bug #54461, CVE-2010-3838)

  • Security Fix: Queries with nested joins could cause an infinite loop in the server when used from stored procedures and prepared statements. (Bug #53544, CVE-2010-3839)

  • Security Fix: The PolyFromWKB() function could crash the server when improper WKB data was passed to the function. (Bug #51875, Bug #11759554, CVE-2010-3840)

  • Incompatible Change; Replication: As of MySQL 5.5.6, handling of CREATE TABLE IF NOT EXISTS ... SELECT statements has been changed for the case that the destination table already exists:

    • Previously, for CREATE TABLE IF NOT EXISTS ... SELECT, MySQL produced a warning that the table exists, but inserted the rows and wrote the statement to the binary log anyway. By contrast, CREATE TABLE ... SELECT (without IF NOT EXISTS) failed with an error, but MySQL inserted no rows and did not write the statement to the binary log.

    • MySQL now handles both statements the same way when the destination table exists, in that neither statement inserts rows or is written to the binary log. The difference between them is that MySQL produces a warning when IF NOT EXISTS is present and an error when it is not.

    This change in handling of IF NOT EXISTS results in an incompatibility for statement-based replication from a MySQL 5.1 master with the original behavior and a MySQL 5.5 slave with the new behavior. Suppose that CREATE TABLE IF NOT EXISTS ... SELECT is executed on the master and the destination table exists. The result is that rows are inserted on the master but not on the slave. (Row-based replication does not have this problem.)

    To address this issue, statement-based binary logging for CREATE TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1 as of 5.1.51:

    This change provides forward compatibility for statement-based replication from MySQL 5.1 to 5.5 because when the destination table exists, the rows will be inserted on both the master and slave. To take advantage of this compatibility measure, the 5.1 server must be at least 5.1.51 and the 5.5 server must be at least 5.5.6.

    To upgrade an existing 5.1-to-5.5 replication scenario, upgrade the master first to 5.1.51 or higher. Note that this differs from the usual replication upgrade advice of upgrading the slave first.

    A workaround for applications that wish to achieve the original effect (rows inserted regardless of whether the destination table exists) is to use CREATE TABLE IF NOT EXISTS and INSERT ... SELECT statements rather than CREATE TABLE IF NOT EXISTS ... SELECT statements.

    Along with the change just described, the following related change was made: Previously, if an existing view was named as the destination table for CREATE TABLE IF NOT EXISTS ... SELECT, rows were inserted into the underlying base table and the statement was written to the binary log. As of MySQL 5.1.51 and 5.5.6, nothing is inserted or logged. (Bug #47442, Bug #47132, Bug #48814, Bug #49494)

  • Important Change; InnoDB: The server could crash with an assertion, possibly leading to data corruption, while updating the primary key of an InnoDB table containing BLOB or other columns requiring off-page storage. This fix applies to the InnoDB Plugin in MySQL 5.1, and to InnoDB 1.1 in MySQL 5.5. (Bug #55543)

  • InnoDB: When MySQL was restarted after a crash with the option innodb_force_recovery=6, certain queries against InnoDB tables could fail, depending on WHERE or ORDER BY clauses.

    Usually in such a disaster recovery situation, you dump the entire table using a query without these clauses. During advanced troubleshooting, you might use queries with these clauses to diagnose the position of the corrupted data, or to recover data following the corrupted part. (Bug #55832)

  • InnoDB: The CHECK TABLE command could cause a time-consuming verification of the InnoDB adaptive hash index memory structure. Now this extra checking is only performed in binaries built for debugging. (Bug #55716)

  • InnoDB: A heavy workload with a large number of threads could cause a crash in the debug version of the server. (Bug #55699)

  • InnoDB: If the server crashed during a RENAME TABLE operation on an InnoDB table, subsequent crash recovery could fail. This problem could also affect an ALTER TABLE statement that caused a rename operation internally. (Bug #55027)

  • InnoDB: The server could crash when opening an InnoDB table linked through foreign keys to a long chain of child tables. (Bug #54582, Bug #11762038)

  • Partitioning: When the storage engine used to create a partitioned table was disabled, attempting to drop the table caused the server to crash. (Bug #46086)

  • If a view was named as the destination table for CREATE TABLE ... SELECT, the server produced a warning whether or not IF NOT EXISTS was used. Now it produces a warning only when IF NOT EXISTS is used, and an error otherwise. (Bug #55777)

  • After the fix for Bug #39653, the shortest available secondary index was used for full table scans. The primary clustered key was used only if no secondary index could be used. However, when the chosen secondary index includes all columns of the table being scanned, it is better to use the primary index because the amount of data to scan is the same but the primary index is clustered. This is now taken into account. (Bug #55656)

  • The server was not checking for errors generated during the execution of Item::val_xxx() methods when copying data to a group, order, or distinct temp table's row. (Bug #55580)

  • ORDER BY clauses that included user-variable expressions could raise a debug assertion. (Bug #55565)

  • Assignment of InnoDB scalar subquery results to a variable resulted in unexpected S locks in READ COMMITTED transaction isolation level. (Bug #55382)

  • Queries involving predicates of the form const NOT BETWEEN not_indexed_column AND indexed_column could return incorrect data due to incorrect handling by the range optimizer. (Bug #54802)

  • MIN() or MAX() with a subquery argument could raise a debug assertion for debug builds or return incorrect data for nondebug builds. (Bug #54465)

  • INFORMATION_SCHEMA plugins with no deinit() method resulted in a memory leak. (Bug #54253)

  • After ALTER TABLE was used on a temporary transactional table locked by LOCK TABLES, any later attempts to execute LOCK TABLES or UNLOCK TABLES caused a server crash. (Bug #54117)

  • INSERT IGNORE INTO ... SELECT statements could raise a debug assertion. (Bug #54106)

  • INFORMATION_SCHEMA.COLUMNS reported incorrect precision for BIGINT UNSIGNED columns. (Bug #53814)

  • The fix for Bug #30234 caused the server to reject the DELETE tbl_name.* ... Access compatibility syntax for multiple-table DELETE statements. (Bug #53034)

  • XA START had a race condition that could cause a server crash. (Bug #51855)

  • Enumeration plugin variables were subject to a type-casting error, causing inconsistent results between different platforms. (Bug #42144)

  • A PKG install on Solaris put some files in incorrect locations. (Bug #31058)

  • Problems in the atomic operations implementation could lead to server crashes. (Bug #22320, Bug #52261)

Download these Release Notes
PDF (US Ltr) - 2.1Mb
PDF (A4) - 2.1Mb
EPUB - 0.5Mb