This is a new Beta development release, fixing recently discovered bugs.
This Beta release, as any other pre-production release, should not be installed on production level systems or systems with critical data. It is good practice to back up your data before installing any new version of software. Although MySQL has worked very hard to ensure a high level of quality, protect your data by making a backup as you would for any software beta release. Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
This section documents all changes and bug fixes that have been applied since the last official MySQL release. If you would like to receive more fine-grained and personalized update alerts about fixes that are relevant to the version and features you use, please consider subscribing to MySQL Enterprise (a commercial MySQL offering). For more details, please see (http://www.mysql.com/products/enterprise).
Functionality Added or Changed
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.
Formerly, restoring a cluster backup made on a MySQL 5.0 Cluster
to a 5.1 cluster using a 5.1 version of
ndb_restore did not resize
VARCHAR columns as might be
expected; now, the default behavior of
ndb_restore in such cases is to resize the
VARCHAR columns. This changed
default behavior can be overridden using the
when invoking ndb_restore.
The data type used for the
column of the following
tables has been changed to
For more information, see The
INFORMATION_SCHEMA GLOBAL_STATUS and
SESSION_STATUS Tables, and
INFORMATION_SCHEMA GLOBAL_VARIABLES and
References: See also Bug #26994.
A new status variable,
indicates the number of calls to stored procedures.
Security Fix: UDFs are supposed to be loadable only from the plugin directory, but this restriction was not being enforced. (Bug #28341)
Security Fix: Use of a view could enable a user to gain update privileges for tables in other databases. (Bug #27878, CVE-2007-3782)
MySQL Cluster: DDL operations were not supported on a partially started cluster. (Bug #24631)
MySQL Cluster: Multiple operations involving deletes followed by reads were not handled correctly.
This issue could also affect MySQL Cluster Replication.
Local checkpoint files relating to dropped
NDB tables were not removed.
MySQL Cluster: Restarting a data node caused SQL nodes to log repeatedly and unnecessarily the status of the event buffer, causing a memory leak of approximately 4 MB for each mysqld process each time this occurred.
(This issue was known to occur in MySQL 5.1.16 and later only.) (Bug #27292)
A delay in obtaining
AUTO_INCREMENT IDs could
lead to excess temporary errors.
ndb_connectstring did not appear in the
When an API node sent more than 1024 signals in a single batch,
NDB would process only the first
1024 of these, and then hang.
MySQL Cluster: A failure to release internal resources following an error could lead to problems with single user mode. (Bug #25818)
Repeated insertion of data generated by
NDB tables could eventually lead to
failure of the cluster.
ndb_mgmd failed silently when the cluster
configuration file contained invalid
Disk Data: Extremely large inserts into Disk Data tables could lead to data node failure in some circumstances. (Bug #27942)
In a multi-operation transaction, a delete operation followed by
the insertion of an implicit
NULL failed to
overwrite an existing value.
The error message for error number
not report which database/table combination reported the
Portability problems caused by use of
Changing the size of a key buffer that is under heavy use could
cause a server crash. The fix partially removes the limitation
LOAD INDEX INTO
CACHE fails unless all indexes in a table have the
same block size. Now the statement fails only if
LEAVES is specified.
A query with a
NOT IN subquery predicate
could cause a crash when the left operand of the predicate
A statement of the form
TABLE IF NOT EXISTS t1 SELECT f1() AS i failed with a
deadlock error if the stored function
referred to a table with the same name as the to-be-created
table. Now it correctly produces a message that the table
Some test suite files were missing from some MySQL-test packages. (Bug #26609)
Views ignored precision for
mysql_upgrade failed if certain SQL modes were set. Now it sets the mode itself to avoid this problem. (Bug #28401)
InnoDB, in some rare cases the optimizer
preferred a more expensive
ref access to a less
expensive range access.
The second execution of a prepared statement from a
UNION query with
BY RAND() caused the server to crash. This problem
could also occur when invoking a stored procedure containing
such a query.
Grouping queries with correlated subqueries in
WHERE conditions could produce incorrect
TABLE IF NOT EXISTS ... SELECT caused a server crash
if the target table already existed and had a
Quoted labels in stored routines were mishandled, rendering the routines unusable. (Bug #21513)
A buffer overflow could occur when using
DECIMAL columns on Windows
Flow control optimization in stored routines could cause exception handlers to never return or execute incorrect logic. (Bug #26977)
EXPLAIN for a query on an empty
table immediately after its creation could result in a server
MIN() on an indexed
column that contained only
NULL values caused
NULL to be returned for other result columns.
Changes to some system variables should invalidate statements in the query cache, but invalidation did not happen. (Bug #27792)
ALTER TABLE statements that
worked in MySQL 5.0 did not work in 5.1.
CURDATE() is less than
NOW(), either when comparing
CURDATE() < NOW() is true) or when
DATE) < NOW() is true). However, storing
CURDATE() in a
DATE column and comparing
incorrectly yielded false. This is fixed by
DATE column as
DATETIME for comparisons to a
A large filesort could result in a division by zero error and a server crash. (Bug #27119)
DATETIME column value
with a user variable yielded incorrect results.
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.
InnoDB variables were missing from the
output of mysqld --verbose --help.
The server could hang for
INSERT IGNORE ... ON
DUPLICATE KEY UPDATE if an update failed.
When dumping procedures, mysqldump
output that restored the session variable
sql_mode without first
capturing it. When dumping routines, mysqldump
set nor retrieved the value of
It was not possible to use the value
–9223372036854775808 (that is,
–MAXVALUE + 1) when specifying a
libmysql.dll could not be dynamically loaded
For dates with 4-digit year parts less than 200, an incorrect
implicit conversion to add a century was applied for date
arithmetic performed with
- INTERVAL. (For
INTERVAL 0 SECOND) became
TEXT local variable in a
stored routine in an expression such as
an incorrect result.