If you intend to use the plugin version of
InnoDB, we recommend that you use
MySQL 5.1.48 or later instead of 5.1.46sp1. This is because
5.1.46 contains the first production-ready version and the
later version has fixes for some of the bugs found during more
widespread production use.
InnoDB Plugin has been upgraded to version
1.0.7. This version is considered of General Availability (GA)
quality. InnoDB Storage Engine Change History, may contain
information in addition to those changes reported here.
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.
Privilege checking for
PLUGIN was incorrect.
(Bug #51770, CVE-2010-1621)
The redo scan during
InnoDB recovery used
excessive CPU. The efficiency of this scan was improved for
InnoDB Plugin, significantly speeding up
(Bug #49535, Bug #29847)
InnoDB Plugin page-freeing operations were
made faster for compressed blocks, speeding up
DROP TABLE, and other operations
on compressed tables that free compressed blocks. One symptom of
the older behavior could be 100% CPU use during these
While looking for the shortest index for a covering index scan,
the optimizer did not consider the full row length for a
clustered primary key, as in
InnoDB. Secondary covering indexes
are now preferred, making full table scans less likely.
References: See also Bug #55656.
When using fast
different internal ordering of indexes in the MySQL optimizer
InnoDB storage engine could
cause error messages about possibly mixed up
.frm files and incorrect index use.
Column length information generated by
InnoDB did not match that generated
MyISAM, which caused invalid
metadata to be written to the binary log when trying to
InnoDB Plugin, bit fields were causing
problems with concurrency on SMP systems because of word-packing
InnoDB: Fixed a performance issue on Windows systems that affected the InnoDB Plugin, by turning off atomic instructions. (Bug #52102)
The AIX implementation of
Partition pruning on
RANGE partitioned tables
did not always work correctly; the last partition was not
excluded if the range was beyond it (when not using
MAXVALUE). Now the last partition is not
included if the partitioning function value is not within the
Foreign keys are not supported on partitioned tables. However,
it was possible using an
TABLE statement to set a foreign key on a partitioned
table; it was also possible to partition a table with a single
GROUP BY queries performed poorly for some
partitioned tables. This was due to the block size not being set
for partitioned tables, thus the keys per block was not correct,
which could cause such queries to be optimized incorrectly.
References: See also Bug #37252.
Replication: When using temporary tables, the binary log needs to insert a pseudo-thread ID for threads that are using temporary tables, each time a switch happens between two threads, both of which are using temporary tables. However, if a thread issued a failing statement before exit, its ID was not recorded in the binary log, and this in turn caused the ID for the next thread that tried to do something with a temporary table not to be logged as well. Subsequent replays of the binary log failed with the error Table ... doesn't exist. (Bug #51226)
References: This bug is a regression of Bug #35583.
If the master was using
duplicate key errors were not sent to the slave, which received
0 rather than the expected error code. This
caused replication to fail even when such an error was expected.
CREATE EVENT statement was
followed by an additional statement and the statements were
executed together as a single statement, the
CREATE EVENT statement was padded
with “garbage” characters when written to the
binary log. This led to a syntax error when the event was read
from the log.
The value of
Slave_IO_running in the output
SHOW SLAVE STATUS did not
distinguish between all 3 possible states of the slave I/O
thread (not running; running but not connected; connected). Now
Connecting (rather than
No) is shown when the slave I/O thread is
running but the slave is not connected to a replication master.
The server system variable
reflects this change, and is now consistent with what is shown
(Bug #30703, Bug #41613, Bug #51089)
The optimizer could attempt to evaluate the
WHERE clause before any rows had been read,
resulting in a server crash.
cause a crash for some pathnames.
INFILE, using a
SET clause to set a
column equal to itself caused a server crash.
A problem with equality propagation optimization for prepared statements and stored procedures caused a server crash upon re-execution of the prepared statement or stored procedure. (Bug #51650)
References: See also Bug #8115, Bug #8849.
The server crashed when the optimizer attempted to determine constant tables but a table storage engine did not support exact record count. (Bug #51494)
A unique index on a column prefix could not be upgraded to a primary index even if there was no primary index already defined. (Bug #51378)
The server could crash populating the
table due to lack of mutex protection.
HANDLER statements with
tables that had spatial indexes caused a server crash.
With an XA transaction active,
SET autocommit =
1 could cause side effects such as memory corruption
or a server crash.
CHECKSUM TABLE could compute the
BIT columns incorrectly.
HAVING clause on a joined table in some
cases failed to eliminate rows which should have been excluded
from the result set.
The type inference used for view columns caused some columns in
views to be handled as the wrong type, as compared to the same
columns in base tables.
columns in base tables were treated as
TIME columns in views, and base
TIME columns as view
0000 could be
treated as equal.
Performing a single in-place
ADD INDEX and
DROP INDEX options that used the same index
name could result in a corrupt table definition file. Now such
ALTER TABLE statements are no
longer performed in place.
mysql_upgrade did not detect when
CSV log tables incorrectly
contained columns that could be
these columns are altered to be
InnoDB returned an error when
inserting a negative value into an auto-increment column.
InnoDB did not reset table
AUTO_INCREMENT values to the last used values
after a server restart.
If a stored function contained a
RETURN statement with an
ENUM value in the
SELECT DTD_IDENTIFIER FROM
INFORMATION_SCHEMA.ROUTINES returned incorrect values.
A trigger could change the behavior of assigning
NULL to a
NOT NULL column.
The server crashed when it could not determine the best
execution plan for queries involving outer joins with
ON clauses such as the ones
RAND() function, a
user-defined function, or a
MERGE engine failed to open a
child table from a different database if the child table or
database name contained characters that were subject to table
name to file name encoding.
MERGE engine did not
properly open a child table from the same database if the child
table name contained characters such as
A query that read from a derived table (of the form
SELECT ... FROM (SELECT ...)) produced
incorrect results when the following conditions were present:
The table subquery contained a derived query
(SELECT ...) AS
The derived query could potentially produce zero rows or a
NULL (that is, no rows matched, or
the query used an aggregate function such as
SUM() running over zero
The table subquery joined at least two tables.
The join condition involved an index.
The optimization to read
MAX() values from an index did
not properly handle comparisons with
values. This could produce incorrect results for
WHERE clause tested a
NULL column for
Killing a query during the optimization phase of a subquery could cause a server crash. (Bug #47761)
Renaming a column of an
table caused the server to go out of sync with the
InnoDB data dictionary. To avoid
this issue, renaming a column uses the older technique of
copying all the table data rather than updating the table
MyISAM could write uninitialized
data to new index pages. Now zeros are written to unused bytes
in the pages.
In debug builds, if the listed columns in the view definition of
the table used in an
SELECT statement mismatched, an assertion was raised
in the query cache invalidation code following the failing
For a query that selected from a view and used an alias for the
view, the metadata used the alias name rather than the view name
mysql_upgrade did not create temporary files properly. (Bug #41057)
If the arguments to a
call included a local routine variable, selecting the return
value into a user variable could produce an incorrect result.
SHOW CREATE VIEW returned invalid
SQL if the definition contained a
string was longer than the
maximum length of a column name, due to the fact that this text
was also used as an alias (in the
Because not all names retrieved from arbitrary
SELECT statements can be used as
view column names due to length and format restrictions, the
server now checks the conformity of automatically generated
column names and rewrites according to a predefined format any
names that are not acceptable as view column names before
storing the final view definition on disk.
In such cases, the name is now rewritten as
pos is the position of the
column. To avoid this conversion scheme, define explicit, valid
names for view columns using the
column_list clause of the
CREATE VIEW statement.
As part of this fix, aliases are now generated only for top-level statements. (Bug #40277)
mysqlbinlog option-processing code had a memory leak. (Bug #38468)
The test for
readline during configuration
failed when trying to build MySQL in a directory other than the
source tree root.
A query on a
FEDERATED table in which the
data was ordered by a
TEXT column returned
incorrect results. For example, a query such as the following
produced incorrect results if column
SELECT * FROM table1 ORDER BY column1;