InnoDB Plugin Notes
This release includes
InnoDB Plugin 1.0.6.
This version is considered of Release Candidate (RC) 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
system variable. Enabling this variable causes updates using the
statement-based logging format to tables using nontransactional
engines to be written directly to the binary log, rather than to
the transaction cache.
Before enabling this variable, be certain that you have no
dependencies between transactional and nontransactional tables.
A statement that both selects from an
InnoDB table and inserts into a
MyISAM table is an example of such
a dependency. For more information, see
Binary Log Options and Variables.
References: See also Bug #28976, Bug #40116.
The method for comparing
names and database names was nonoptimal and an improvement was
made: When the database name length is already known, a length
check is made first and content comparison skipped if the
lengths are unequal.
... REORGANIZE PARTITION statement on an
InnoDB table failed due to
expiring while waiting for a lock,
not clean up any temporary files or tables which it had created.
Attempting to reissue the
TABLE statement following the timeout could lead to
storage engine errors, or possibly a crash of the server.
InnoDB: Creating or dropping a table with 1023 transactions active caused an assertion failure. (Bug #49238)
set to 4 or higher, the server could crash when opening an
InnoDB table containing an
auto-increment column. MySQL versions 5.1.31 and later were
Replication: In some cases, inserting into a table with many columns could cause the binary log to become corrupted. (Bug #50018)
References: See also Bug #42749.
When using row-based replication, setting a
CHAR column of a
MyISAM table to
NULL, then trying to delete from the table,
caused the slave to fail with the error Can't find
(Bug #49481, Bug #49482)
When logging in row-based mode, DDL statements are actually
logged as statements; however, statements that affected
temporary tables and followed DDL statements failed to reset the
binary log format to
ROW, with the result
that these statements were logged using the statement-based
format. Now the state of
binlog_format is restored after
a DDL statement has been written to the binary log.
When using row-based logging, the statement
CREATE TABLE t IF
NOT EXIST ... SELECT was logged as
TABLE t IF NOT EXIST ... SELECT when
t already existed as a temporary table. This
was caused by the fact that the temporary table was opened and
the results of the
inserted into it when a temporary table existed and had the same
Now, when this statement is executed,
created as a base table, the results of the
SELECT are inserted into
it—even if there already exists a temporary table having
the same name—and the statement is logged correctly.
References: See also Bug #47442.
Due to a change in the size of event representations in the
binary log, when replicating from a MySQL 4.1 master to a slave
running MySQL 5.0.60 or later, the
UNTIL statement did not function correctly, stopping
at the wrong position in the log. Now the slave detects that the
master is using the older version of the binary log format, and
corrects for the difference in event size, so that the slave
stops in the correct position.
printstack function does not exist on
Solaris 8 or earlier, which led to a compilation failure.
The SSL certificates in the test suite were about to expire. They have been updated with expiration dates in the year 2015. (Bug #50642)
Debug output for join structures was garbled. (Bug #50271)
A user could see tables in
appropriate privileges for them.
mysql-test-run.pl now recognizes the
MTR_START_TIMEOUT environment variables. If
they are set, their values are used to set the
--start-timeout options, respectively.
Mixing full-text searches and row expressions caused a crash. (Bug #49445)
filesort sorting method applied to a
CHAR(0) column could lead to a
In some cases a subquery need not be evaluated because it returns only aggregate values that can be calculated from table metadata. This sometimes was not handled by the enclosing subquery, resulting in a server crash. (Bug #49512)
The optimizer could continue to execute a query after a storage engine reported an error, leading to a server crash. (Bug #46175)