This is a Monthly Rapid Update release of the MySQL Enterprise Server 5.0.
This section documents all changes and bug fixes that have been applied since the last MySQL Enterprise Server release (5.0.40).
Functionality Added or Changed
Prior to this release, when
values were compared with
DATETIME values, the time portion
DATETIME value was
ignored, or the comparison could be performed as a string
compare. Now a
DATE value is
coerced to the
DATETIME type by
adding the time portion as
00:00:00. To mimic
the old behavior, use the
function as shown in this example:
date_col = CAST(NOW() AS DATE) FROM
This was done to resolve the following interrelated issues:
The server could abort or deadlock for
INSERT DELAYED statements for
which another insert was performed implicitly (for example,
using a stored function that inserted a row).
A trigger using an
DELAYED caused the error INSERT DELAYED
can't be used with table ... because it is locked with LOCK
TABLES although the target table was not
INSERT DELAYED into a table
BEFORE INSERT or
INSERT trigger gave an incorrect
NEW pseudocolumn value and caused the
server to deadlock or abort.
References: See also Bug #20497, Bug #21714.
mysqld_multi now understands the
option is deprecated; if given, it is treated like
Security Fix: Use of a view could enable a user to gain update privileges for tables in other databases. (Bug #27878, CVE-2007-3782)
If a stored routine was declared using
INVOKER, a user who invoked the routine could gain
(Bug #27337, CVE-2007-2692)
MySQL Cluster: The cluster waited 30 seconds instead of 30 milliseconds before reading table statistics. (Bug #28093)
NULL values in unique
MySQL Cluster: The name of the month “March” was given incorrectly in the cluster error log. (Bug #27926)
It was not possible to add a unique index to an
NDB table while in single user
Repeated insertion of data generated by
NDB tables could eventually lead to
failure of the cluster.
ndb_connectstring did not appear in the
Replication: Aborting a statement on the master that applied to a nontransactional statement broke replication. The statement was written to the binary log but not completely executed on the master. Slaves receiving the statement executed it completely, resulting in loss of data synchrony. Now an error code is written to the error log so that the slaves stop without executing the aborted statement. (That is, replication stops, but synchrony to the point of the stop is preserved and you can investigate the problem.) (Bug #26551)
Replication: Restoration of the default database after stored routine or trigger execution on a slave could cause replication to stop if the database no longer existed. (Bug #25082)
BLOB reads on operations with
LM_CommittedRead, the lock mode was
not upgraded to
LM_Read before the state of
BLOB had already been
NDB API methods
affected by this problem included the following:
On the IBM i5 platform, the installation script in the
.savf binaries unconditionally executed the
mysql_install_db script. This problem was
fixed in a repackaged distribution numbered 5.0.42b.
A query with a
NOT IN subquery predicate
could cause a crash when the left operand of the predicate
InnoDB, in some rare cases the optimizer
preferred a more expensive
ref access to a less
expensive range access.
A performance degradation was observed for outer join queries to which a not-exists optimization was applied. (Bug #28188)
SELECT * INTO OUTFILE ... FROM
INFORMATION_SCHEMA.SCHEMATA failed with an
Access denied error, even for a user who
The server could hang for
INSERT IGNORE ... ON
DUPLICATE KEY UPDATE if an update failed.
... ON DUPLICATE KEY UPDATE statements that affected
many rows, updates could be applied to the wrong rows.
NULL-filtering optimization did not
eq_ref table access.
Views ignored precision for
Nongrouped columns were permitted by
ONLY_FULL_GROUP_BY SQL mode.
Debug builds on Windows generated false alarms about uninitialized variables with some Visual Studio runtime libraries. (Bug #27811)
Certain queries that used uncorrelated scalar subqueries caused
EXPLAIN to crash.
Changes to some system variables should invalidate statements in the query cache, but invalidation did not happen. (Bug #27792)
UNION on two views
ORDER BY clauses resulted in an
Unknown column error.
mysql_install_db is supposed to detect existing system tables and create only those that do not exist. Instead, it was exiting with an error if tables already existed. (Bug #27783)
mysqld did not check the length of option values and could crash with a buffer overflow for long values. (Bug #27715)
Comparisons using row constructors could fail for rows
mysqldump could not connect using SSL. (Bug #27669)
InnoDB tables, a multiple-row
INSERT of the form
INSERT INTO t (id...) VALUES (NULL...) ON DUPLICATE KEY
UPDATE id=VALUES(id), where
AUTO_INCREMENT column, could cause
ERROR 1062 (23000): Duplicate entry... errors
or lost rows.
The XML output representing an empty result was an empty string
rather than an empty
References: See also Bug #32198.
The fix for Bug #17212 provided correct sort order for misordered output of certain queries, but caused significant overall query performance degradation. (Results were correct (good), but returned much more slowly (bad).) The fix also affected performance of queries for which results were correct. The performance degradation has been addressed. (Bug #27531)
CRC32() function returns an
unsigned integer, but the metadata was signed, which could cause
certain queries to return incorrect results. (For example,
queries that selected a
value and used that value in the
An interaction between
STATUS and other concurrent statements that modify the
table could result in a divide-by-zero error and a server crash.
Nested aggregate functions could be improperly evaluated. (Bug #27363)
A stored function invocation in the
clause was treated as a constant.
Failure to allocate memory associated with
cause a server crash.
mysqldump crashed if it got no data from
SHOW CREATE PROCEDURE (for
example, when trying to dump a routine defined by a different
user and for which the current user had no privileges). Now it
prints a comment to indicate the problem. It also returns an
error, or continues if the
--force option is
mysqlbinlog produced different output with
-R option than without it.
Flow control optimization in stored routines could cause exception handlers to never return or execute incorrect logic. (Bug #26977)
mysqldump would not dump a view for which the
DEFINER no longer exists.
Creating a temporary table with
using the one-file-per-table setting, and when the host file
system for temporary tables was
cause an assertion within
mysqld. This was
due to the use of
O_DIRECT when opening the
temporary table file.
mysql_upgrade did not detect failure of external commands that it runs. (Bug #26639)
Index hints (
FORCE INDEX) cannot be used
FULLTEXT indexes, but were not being
CREATE TABLE t1
LIKE t2 failed due to a full disk, an empty
t2.frm file could be created but not
removed. This file then caused subsequent attempts to create a
t2 to fail. This is easily
corrected at the file system level by removing the
t2.frm file manually, but now the server
removes the file if the create operation does not complete
mysql_upgrade did not pass a password to mysqlcheck if one was given. (Bug #25452)
On Windows, mysql_upgrade was sensitive to lettercase of the names of some required components. (Bug #25405)
For storage engines that permit the current auto-increment value
to be set, using
ALTER TABLE ... ENGINE to
convert a table from one such storage engine to another caused
loss of the current value. (For storage engines that do not
support setting the value, it cannot be retained anyway when
changing the storage engine.)
Several math functions produced incorrect results for large
incorrect results or a crash for a large number-of-decimals
The result set of a query that used
DISTINCT could lack some
rollup rows (rows with
NULL values for
grouping attributes) if the
GROUP BY list
contained constant expressions.
For queries that used
ORDER BY with
InnoDB tables, if the optimizer chose an
index for accessing the table but found a covering index that
ORDER BY to be skipped, no
results were returned.
Concurrent execution of
CREATE TABLE ...
SELECT and other statements involving the target table
suffered from various race conditions, some of which might have
led to deadlocks.
An attempt to execute
CREATE TABLE ...
SELECT when a temporary table with the same name
already existed led to the insertion of data into the temporary
table and creation of an empty nontemporary table.
MERGE storage engine could return
incorrect results when several index values that compare
equality were present in an index (for example,
which are considered equal but have different lengths).
Some upgrade problems are detected and better error messages suggesting that mysql_upgrade be run are produced. (Bug #24248)
Some views could not be created even when the user had the requisite privileges. (Bug #24040)
AUTO_INCREMENT value would not be
correctly reported for
InnoDB tables when
SHOW CREATE TABLE statement
or mysqldump command.
SELECT COUNT(*) from a table containing a
DATETIME NOT NULL column could produce
spurious warnings with the
NO_ZERO_DATE SQL mode enabled.
return an incorrect rows-matched value if, during insertion of
rows into a temporary table, the table had to be converted from
MEMORY table to a
yaSSL crashed on pre-Pentium Intel CPUs. (Bug #21765)
A slave that used
could not connect to the master.
Quoted labels in stored routines were mishandled, rendering the routines unusable. (Bug #21513)
TABLE IF NOT EXISTS ... SELECT caused a server crash
if the target table already existed and had a
utf8 column in an
InnoDB table to a shorter length did not
shorten the data values.
The omission of leading zeros in dates could lead to erroneous results when these were compared with the output of certain date and time functions. (Bug #16377)
INSERT...ON DUPLICATE KEY UPDATE could cause
Error 1032: Can't find record in ... for
inserts into an
InnoDB table unique index
using key column prefixes with an underlying
utf8 string column.
EXECUTE privilege for
a routine in a database should make it possible to
USE that database, but the server
returned an error instead. This has been corrected. As a result
of the change,
SHOW TABLES for a
database in which you have only the
EXECUTE privilege returns an
empty set rather than an error.