This release includes
InnoDB Plugin1.0.6. This version is considered of Release Candidate (RC) quality.
In this release, the
InnoDB Pluginis 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.
Replication: Introduced the
binlog_direct_non_transactional_updatessystem 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
InnoDBtable and inserts into a
MyISAMtable is an example of such a dependency. For more information, see Binary Log Options and Variables. (Bug #46364)
References: See also Bug #28976, Bug #40116.
Performance: The method for comparing
INFORMATION_SCHEMAnames 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. (Bug #49501)
InnoDB; Partitioning: When an
ALTER TABLE ... REORGANIZE PARTITIONstatement on an
InnoDBtable failed due to
innodb_lock_wait_timeoutexpiring while waiting for a lock,
InnoDBdid not clean up any temporary files or tables which it had created. Attempting to reissue the
ALTER TABLEstatement following the timeout could lead to storage engine errors, or possibly a crash of the server. (Bug #47343)
InnoDB: Creating or dropping a table with 1023 transactions active caused an assertion failure. (Bug #49238)
innodb_force_recoverywas set to 4 or higher, the server could crash when opening an
InnoDBtable containing an auto-increment column. MySQL versions 5.1.31 and later were affected. (Bug #46193)
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.
Replication: When using row-based replication, setting a
CHARcolumn of a
NULL, then trying to delete from the table, caused the slave to fail with the error Can't find record in
table. (Bug #49481, Bug #49482)
Replication: 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_formatis restored after a DDL statement has been written to the binary log. (Bug #49132)
Replication: When using row-based logging, the statement
CREATE TABLE t IF NOT EXIST ... SELECTwas logged as
CREATE TEMPORARY TABLE t IF NOT EXIST ... SELECTwhen
talready existed as a temporary table. This was caused by the fact that the temporary table was opened and the results of the
SELECTwere inserted into it when a temporary table existed and had the same name.
Now, when this statement is executed,
tis created as a base table, the results of the
SELECTare inserted into it—even if there already exists a temporary table having the same name—and the statement is logged correctly. (Bug #47418)
References: See also Bug #47442.
Replication: 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
START SLAVE UNTILstatement 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. (Bug #47142)
The SSL certificates in the test suite were about to expire. They have been updated with expiration dates in the year 2015. (Bug #50642)
printstackfunction does not exist on Solaris 8 or earlier, which led to a compilation failure. (Bug #50409)
A user could see tables in
INFORMATION_SCHEMA.TABLESwithout appropriate privileges for them. (Bug #50276)
Debug output for join structures was garbled. (Bug #50271)
filesortsorting method applied to a
CHAR(0)column could lead to a server crash. (Bug #49897)
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)
Mixing full-text searches and row expressions caused a crash. (Bug #49445)
mysql-test-run.pl now recognizes the
MTR_START_TIMEOUTenvironment variables. If they are set, their values are used to set the
--start-timeoutoptions, respectively. (Bug #49210)
The optimizer could continue to execute a query after a storage engine reported an error, leading to a server crash. (Bug #46175)