InnoDB Plugin Notes
InnoDB Plugin has been upgraded to version
1.0.9. 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), generic Linux RPM packages,
and any builds produced with the icc
compiler. It also does not work for FreeBSD 6 and HP-UX or for
Linux on generic ia64.
Functionality Added or Changed
Bugs Fixed
Security Fix: A security bug was fixed. (Bug #53907)
Security Fix: A security bug was fixed. (Bug #48157)
Security Fix: A security bug was fixed. (Bug #52357)
Important Change; Replication:
MyISAM transactions replicated to a
transactional slave left the slave in an unstable condition.
This was due to the fact that, when replicating from a
nontransactional storage engine to a transactional engine with
autocommit disabled, no
BEGIN and
COMMIT statements were written to
the binary log; thus, on the slave, a never-ending transaction
was started.
The fix for this issue includes enforcing
autocommit mode on the slave by
replicating all autocommit=1 statements from
the master.
(Bug #29288)
InnoDB; Replication:
Reading from a table that used a self-logging storage engine and
updating a table that used a transactional engine (such as
InnoDB) generated changes that were written
to the binary log using statement format which could make slaves
diverge. However, when using mixed logging format, such changes
should be written to the binary log using row format. (This
issue did not occur when reading from tables using a
self-logging engine and updating MyISAM
tables, as this was already handled by checking for combinations
of nontransactional and transactional engines.) Now such
statements are classified as unsafe, and in mixed mode, cause a
switch to row-based logging.
(Bug #49019)
InnoDB:
The server could crash with a message InnoDB: Assertion
failure in thread ,
typically during shutdown on a Windows system.
(Bug #53947)nnnn
InnoDB:
Multi-statement execution could fail with an error about foreign
key constraints. This problem could affect calls to
mysql_query() and
mysql_real_query(), and
CALL statements that invoke stored
procedures.
(Bug #48024)
InnoDB:
Fixed a checksum error reported for compressed tables when the
--innodb_checksums option is enabled.
Although the message stated that the table was corrupted, the
table is actually fine.
(Bug #53248)
InnoDB:
Corrected the handling of the setting
innodb_change_buffering=default. (The
appropriate default value is different between MySQL 5.1 and
5.5.)
(Bug #53165)
InnoDB:
Adding a unique key on multiple columns, where one of the
columns is NULL, could mistakenly report
duplicate key errors.
(Bug #53290)
InnoDB: If a crash occurs while creating an index using the InnoDB “Fast Index Creation” mechanism, the partially created index is dropped during the crash recovery processing when the database is restarted.
Partitioning:
When attempting to perform DDL on a partitioned table and the
table's .par file could not be found,
the server returned the inaccurate error message Out
of memory; restart server and try again (needed 2
bytes). Now in such cases, the server returns the
error Failed to initialize partitions from .par
file.
(Bug #49161)
Partitioning:
ALTER
TABLE statements that cause table partitions to be
renamed or dropped (such as ALTER TABLE ... ADD
PARTITION, ALTER TABLE ... DROP
PARTITION, and ALTER TABLE ... REORGANIZE
PARTITION) — when run concurrently with queries
against the
INFORMATION_SCHEMA.PARTITIONS table
— could fail, cause the affected partitioned tables to
become unusable, or both. This was due to the fact that the
INFORMATION_SCHEMA database ignored the name
lock imposed by the ALTER TABLE
statement on the partitions affected. In particular, this led to
problems with InnoDB tables,
because InnoDB would accept the
rename operation, but put it in a background queue, so that
subsequent rename operations failed when
InnoDB was unable to find the
correct partition. Now, INFORMATION_SCHEMA
honors name locks imposed by ongoing ALTER
TABLE statements that cause partitions to be renamed
or dropped.
(Bug #50561)
References: See also Bug #47343, Bug #45808.
Partitioning:
It was possible to execute a CREATE TEMPORARY TABLE tmp
LIKE pt statement, where pt is a
partitioned table, even though partitioned temporary tables are
not permitted. This caused the server to crash. Now a check is
performed to prevent such statements from being executed.
(Bug #49477)
Replication:
In some cases, attempting to update a column with a value of an
incompatible type resulted in a mismatch between master and
slave because the column value was set to its implicit default
value on the master (as expected), but the same column on the
slave was set to NULL.
(Bug #52868)
Replication:
When using a nontransactional table on the master with
autocommit disabled, no COMMIT
was recorded in the binary log following a statement affecting
this table. If the slave's copy of the table used a
transactional storage engine, the result on the slave was as
though a transaction had been started, but never completed.
(Bug #49522)
References: See also Bug #29288.
Using an initial command with
mysql_options(..., MYSQL_INIT_COMMAND,
...) that generated multiple result sets (such as a
stored procedure or a multi-statement command) left the
connection unusable.
(Bug #42373)
mysqldump and
SELECT ... INTO
OUTFILE truncated long
BLOB and
TEXT values to 766 bytes.
(Bug #53088)
UPDATE on an
InnoDB table modifying the same
index that was used to satisfy the WHERE
condition could trigger a debug assertion under some
circumstances.
(Bug #53830)
In the debug version of the server, the
FreeState() function could in some
circumstances be called twice, leading to an assertion failure.
(Bug #52884)
Valgrind warnings resulting from passing incomplete
DATETIME values to the
TIMESTAMP() function were
corrected.
(Bug #53942)
Calculation of intervals for Event Scheduler events was not portable. (Bug #50087)
Selecting from
INFORMATION_SCHEMA.ROUTINES or
INFORMATION_SCHEMA.PARAMETERS
resulted in a memory leak.
(Bug #48729)
Aggregate functions could incorrectly return
NULL in outer join queries.
(Bug #52051)
The Loose Index Scan optimization method assumed that it could depend on the partitioning engine to maintain interval endpoint information, as if it were a storage engine. (Bug #50939)
Incorrect results could be returned for LEFT
JOIN of InnoDB tables
with an impossible WHERE condition.
(Bug #53334)
When the transaction isolation level was
REPEATABLE READ and binary
logging used statement or mixed format,
SELECT statements with subqueries
referencing InnoDB tables
unnecessarily acquired shared locks on rows in these tables.
(Bug #46947)
For single-table DELETE
statements that used quick select and index scan simultaneously
caused a server crash or assertion failure.
(Bug #53450)
MySQL incorrectly processed
ALTER DATABASE
`#mysql50# where
special` UPGRADE DATA
DIRECTORY NAMEspecial was .,
.., or a sequence starting with
./ or ../. It used the
server data directory (which contains other regular databases)
as the database directory.
(Bug #53804, CVE-2010-2008)
InnoDB crashed when replacing
duplicates in a table after a fast ALTER
TABLE added a unique index.
(Bug #53592)
For InnoDB tables, the error
handler for a fast CREATE INDEX
did not reset the error state of the transaction before
attempting to undo a failed operation, resulting in a crash.
(Bug #53591)
On Intel x86 machines, the optimizer could choose different execution plans for a query depending on the compiler version and optimization flags used to build the server binary. (Bug #48537)
For outer joins, the optimizer could fail to properly calculate table dependencies. (Bug #52005)
Setting the
innodb_change_buffering system
variable to DEFAULT produced an incorrect
result.
(Bug #53165)
