This release includes
InnoDB 1.0.6. This
version is considered of Release Candidate (RC) quality.
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.
Security Fix: For servers built with yaSSL, a preauthorization buffer overflow could cause memory corruption or a server crash. We thank Evgeny Legerov from Intevydis for providing us with a proof-of-concept script that permitted us to reproduce this bug. (Bug #50227, CVE-2009-4484)
When used on partitioned tables, the
records_in_range handler call checked more
partitions than necessary. The fix for this issue reduces the
number of unpruned partitions checked for statistics in
partition range checking, which has resulted in some partition
operations being performed up to 2-10 times faster than before
this change was made, when testing with tables having 1024
References: See also Bug #37252, Bug #47261.
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.
MYSQL_REPLICATION_PLUGIN symbol was out of
synchrony with its value in MySQL 6.0 because the lower-valued
MYSQL_AUDIT_PLUGIN was not present. To
MYSQL_AUDIT_PLUGIN has been
added in MySQL 5.5, changing the value of
MYSQL_REPLICATION_PLUGIN from 5 to 6.
Attempts to load the audit plugin produce an error occurs
because only the
was added, not the audit plugin itself. This error will go away
when the audit plugin is added to MySQL 5.5 (in 5.5.3).
Replication plugins from earlier 5.5.x releases must be
recompiled against the current release before they will work
with the current release.
Important Change; Replication:
RAND() function is now marked
as unsafe for statement-based replication. Using this function
now generates a warning when
causes the format to switch to row-based logging when
This change is being introduced because, when
RAND() was logged in statement
mode, the seed was also written to the binary log, so the
replication slave generated the same sequence of random numbers
as was generated on the master. While this could make
replication work in some cases, the order of affected rows was
still not guaranteed when this function was used in statements
that could update multiple rows, such as
SELECT; if the master and the slave retrieved rows in
different order, they began to diverge.
... 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
could in some circumstances crash the server. This occurred
because the I/O thread could concurrently access the relay log
I/O cache while another thread was performing the
which closes and reopens the relay log and, while doing so,
initializes (or re-initializes) its I/O cache. This could cause
problems if some other thread (in this case, the I/O thread) is
accessing it at the same time.
Now the thread performing the
operation takes a lock on the relay log before actually flushing
References: See also Bug #53657.
Replication: With semisynchronous replication, memory allocated for handling transactions could be freed while still in use, resulting in a server crash. (Bug #50157)
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)
INFILE statement that loaded data into a table having
a column name that had to be quoted (such as
INT) caused replication to fail when logging in mixed
or statement mode. In such cases, the master wrote the
LOAD DATA event into the binary
log without quoting the column name.
References: See also Bug #47927. This bug is a regression of Bug #43746.
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.
Replication: Spatial data types caused row-based replication to crash. (Bug #48776)
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.
Replication: Manually removing entries from the binary log index file on a replication master could cause the server to repeatedly send the same binary log file to slaves. (Bug #28421)
The SSL certificates in the test suite were about to expire. They have been updated with expiration dates in the year 2015. (Bug #50642)
SPATIAL indexes were permitted on columns
with nonspatial data types, resulting in a server crash for
subsequent table inserts.
Index prefixes could be specified with a length greater than the associated column, resulting in a server crash for subsequent table inserts. (Bug #50542)
Use of loose index scan optimization for an aggregate function
DISTINCT (for example,
COUNT(DISTINCT)) could produce
printstack function does not exist on
Solaris 8 or earlier, which led to a compilation failure.
A user could see tables in
appropriate privileges for them.
Debug output for join structures was garbled. (Bug #50271)
The server crashed when an
background thread attempted to write a message containing a
partitioned table name to the error log.
Within a stored routine, selecting the result of
CONCAT_WS() with a routine
parameter argument into a user variable could return incorrect
filesort sorting method applied to a
CHAR(0) column could lead to a
EXTENDED UNION ... ORDER BY caused a crash when the
ORDER BY referred to a nonconstant or
full-text function or a subquery.
Some prepared statements could raise an assertion when re-executed. (Bug #49570)
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_TIMEOUT environment variables. If
they are set, their values are used to set the
--start-timeout options, respectively.
strmake() calls had an incorrect
length argument (too large by one).
On Fedora 12,
strmov() did not guarantee
correct operation for overlapping source and destination buffer.
Calls were fixed to use an overlap-safe version instead.
With one thread waiting for a lock on a table, if another thread dropped the table and created a new table with the same name and structure, the first thread did not notice that the table had been re-created and tried to used cached metadata that belonged to the old table but had been freed. (Bug #48157)
If an invocation of a stored procedure failed in the table-open stage, subsequent invocations that did not fail in that stage could cause a crash. (Bug #47649)
A crash occurred when a user variable that was assigned to a
subquery result was used as a result field in a
SELECT statement with aggregate
The optimizer could continue to execute a query after a storage engine reported an error, leading to a server crash. (Bug #46175)
EXPLAIN encountered an error
in the query, a memory leak occurred.
A race condition on the privilege hash tables permitted one
thread to try to delete elements that had already been deleted
by another thread. A consequence was that
PRIVILEGES could cause a crash.
(Bug #35589, Bug #35591)
1) In rare cases, if a thread was interrupted during a
PRIVILEGES operation, a debug assertion occurred later
due to improper diagnostics area setup. 2) A
KILL operation could cause a
console error message referring to a diagnostic area state
without first ensuring that the state existed.
ALTER TABLE with both
DROP COLUMN and
clauses could crash or lock up the server.
variable was not incremented in the cases that a lock had to be
waited for but the waiting thread was killed or the request was