InnoDB Plugin Notes
InnoDB Plugin has been upgraded to version
1.0.12. This version is considered of General Availability (GA)
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
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
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:
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:
References: See also Bug #56821.
Queries could cause a server crash if the
LEAST() function had a mixed list
of numeric and
arguments, and the result of such a function was processed using
an intermediate temporary table.
(Bug #54461, CVE-2010-3838)
During evaluation of arguments to extreme-value functions such
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: 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)
ROLLUP together could cause a server crash.
(Bug #54476, CVE-2010-3837)
LIKE predicates during view
preparation could cause a server crash.
(Bug #54568, Bug #11762026, CVE-2010-3836)
A user-variable assignment expression that is evaluated in a
logical expression context can be precalculated in a temporary
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
(Bug #55564, CVE-2010-3835)
PolyFromWKB() function could
crash the server when improper WKB data was passed to the
(Bug #51875, Bug #11759554, CVE-2010-3840)
Incompatible Change; Replication:
As of MySQL 5.5.6, handling of
TABLE IF NOT EXISTS ... SELECT statements has been
changed for the case that the destination table already exists:
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,
TABLE ... SELECT (without
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
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
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
TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1
as of 5.1.51:
If the destination table does not exist, there is no change: The statement is logged as is.
If the destination table does exist, the statement is logged
as the equivalent pair of
TABLE IF NOT EXISTS and
SELECT statements. (If the
SELECT in the original
statement is preceded by
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
TABLE IF NOT EXISTS and
SELECT statements rather than
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
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.
If the server crashed during a
operation on an
InnoDB table, subsequent
crash recovery could fail. This problem could also affect an
ALTER TABLE statement that caused a rename
InnoDB: A heavy workload with a large number of threads could cause a crash in the debug version of the server. (Bug #55699)
When MySQL was restarted after a crash with the option
innodb_force_recovery=6, certain queries
InnoDB tables could fail, depending
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)
CHECK TABLE command could cause a
time-consuming verification of the
adaptive hash index memory structure. Now this extra checking is
only performed in binaries built for debugging.
The server could crash when opening an
InnoDB table linked through foreign
keys to a long chain of child tables.
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)
incorrect precision for
XA START had a
race condition that could cause a server crash.
Enumeration plugin variables were subject to a type-casting error, causing inconsistent results between different platforms. (Bug #42144)
INTO ... SELECT statements could raise a debug
The server was not checking for errors generated during the
Item::val_xxx() methods when
copying data to a group, order, or distinct temp table's row.
ORDER BY clauses that included user-variable
expressions could raise a debug assertion.
The fix for Bug #30234 caused the server to reject the
DELETE Access compatibility syntax for multiple-table
INFORMATION_SCHEMA plugins with no
deinit() method resulted in a memory leak.
If a view was named as the destination table for
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.
Queries involving predicates of the form
incorrect data due to incorrect handling by the range optimizer.
const NOT BETWEEN
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)
Problems in the atomic operations implementation could lead to server crashes. (Bug #22320, Bug #52261)
A PKG install on Solaris put some files in incorrect locations. (Bug #31058)