This is a Monthly Rapid Update release of the MySQL Enterprise Server 5.0.
This section documents all changes and bugfixes that have been applied since the last MySQL Enterprise Server release (5.0.72). 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/advisors.html.
Functionality Added or Changed
Previously, index hints did not work for
FULLTEXT searches. Now they work as follows:
For natural language mode searches, index hints are silently
ignored. For example,
IGNORE INDEX(i) is
ignored with no warning and the index is still used.
For boolean mode searches, index hints are honored. (Bug #38842)
Queries of the form
SELECT ... WHERE
when the server used a single-byte character set and the client
used a multibyte character set.
string = ANY(...)
References: See also Bug #20835.
CHECK TABLE ... FOR
UPGRADE did not check for incompatible collation
changes made in MySQL 5.0.48 (Bug #27562, Bug #29461, Bug
#29499). This also affects mysqlcheck and
mysql_upgrade, which cause that statement to
be executed. See
Checking Whether Tables or Indexes Must Be Rebuilt.
References: See also Bug #39585.
Support for the
revision field in
.frm files has been removed. This addresses
the downgrading problem introduced by the fix for Bug #17823.
Queries with a
HAVING clause could return a
For a stored procedure containing a
SELECT * ... RIGHT
JOIN query, execution failed for the second call.
With binary logging enabled
VIEW was subject to possible buffer overwrite and a
The mysql client, when built with Visual Studio 2005, did not display Japanese characters. (Bug #36279)
perror on Windows did not know about Win32 system error codes. (Bug #34825)
Statements that displayed the value of system variables (for
SHOW VARIABLES) expect
variable values to be encoded in
variables set from the command line such as
datadir were encoded using
not converted correctly.
SQL mode enabled, the check for nonaggregated columns in queries
with aggregate functions, but without a
BY clause was treating all the parts of the query as
if they were in the select list. This is fixed by ignoring the
nonaggregated columns in the
FEDERATED handler had a memory
Prepared statements permitted invalid dates to be inserted when
mode was not enabled.
References: See also Bug #42525.
TABLES to get the list of tables in a database. For
some problems, such as an empty
for a table, this failed and mysqlcheck then
would neglect to check other tables in the database.
Updating a view with a subquery in the
option could cause an assertion failure.
Previously, use of index hints with views (which do not have indexes) produced the error ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX and VIEW. Now this produces ERROR 1176 (HY000): Key '...' doesn't exist in table '...', the same error as for base tables without an appropriate index. (Bug #33461)
CREATE INDEX could crash with
InnoDB plugin 1.0.1.
If the operating system is configured to return leap seconds
from OS time calls or if the MySQL server uses a time zone
definition that has leap seconds, functions such as
NOW() could return a value having
a time part that ends with
:59:61. If such values are inserted into a
table, they would be dumped as is by
mysqldump but considered invalid when
reloaded, leading to backup/restore problems.
Now leap second values are returned with a time part that ends
:59:59. This means that a function such
NOW() can return the same
value for two or three consecutive seconds during the leap
second. It remains true that literal temporal values having a
time part that ends with
:59:61 are considered invalid.
For additional details about leap-second handling, see Time Zone Leap Second Support. (Bug #39920)
A race condition between the mysqld.exe server and the Windows service manager could lead to inability to stop the server from the service manager. (Bug #20430)
Some division operations produced a result with incorrect precision. (Bug #31616)