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.52). 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
mysql_odbc_escape_string() C API
function has been removed. It has multi-byte character escaping
issues, doesn't honor the
NO_BACKSLASH_ESCAPES SQL mode
and is not needed anymore by Connector/ODBC as of 3.51.17.
References: See also Bug #41728.
The argument for the mysql-test-run.pl
options is now interpreted as a Perl regular expression if there
is a pattern metacharacter in the argument value. This enables
more flexible specification of which tests to perform or skip.
Security Enhancement: It was possible to force an error message of excessive length which could lead to a buffer overflow. This has been made no longer possible as a security precaution. (Bug #32707)
InnoDB had a race condition for an adaptive
hash rw-lock waiting for an X-lock. This fix may also provide
significant speed improvements on systems experiencing problems
with contention for the adaptive hash index.
Incompatible Change: The MySQL 5.0.50 patch for this bug was reverted because it changed the behavior of a General Availability MySQL release. (Bug #30234)
References: See also Bug #27525.
Incompatible Change: It was possible for option files to be read twice at program startup, if some of the standard option file locations turned out to be the same directory. Now duplicates are removed from the list of files to be read.
Also, users could not override system-wide settings using
was read last. The latter file now is read earlier so that
~/.my.cnf can override system-wide
The fix for this problem had a side effect such that on Unix,
MySQL programs looked for options in
~/my.cnf rather than the standard location
~/.my.cnf. That problem was addressed as
SHOW SLAVE STATUS as
mysqld was shutting down could cause a crash.
UPDATE statement using a
stored function that modified a nontransactional table was not
logged if it failed. This caused the copy of the
nontransactional table on the master have a row that the copy on
the slave did not.
In addition, when an
ON DUPLICATE KEY UPDATE statement encountered a
duplicate key constraint, but the
UPDATE did not actually change
any data, the statement was not logged. As a result of this fix,
such statements are now treated the same for logging purposes as
UPDATE statements, and so
are written to the binary log.
References: See also Bug #12713.
Replication: It was possible for the name of the relay log file to exceed the amount of memory reserved for it, possibly leading to a crash of the server. (Bug #31836)
References: See also Bug #28597.
Replication: One thread could read uninitialized memory from the stack of another thread. This issue was only known to occur in a mysqld process acting as both a master and a slave. (Bug #30752)
Replication: Due a previous change in how the default name and location of the binary log file were determined, replication failed following some upgrades. (Bug #28597, Bug #28603)
References: See also Bug #31836. This bug was introduced by Bug #20166.
Stored procedures having
parameters were not replicated correctly.
A replication slave sometimes failed to reconnect because it was
unable to run
SHOW SLAVE HOSTS.
It was not necessary to run this statement on slaves (since the
master should track connection IDs), and the execution of this
statement by slaves was removed.
References: See also Bug #13963, Bug #21869.
Replication: Corruption of log events caused the server to crash on 64-bit Linux systems having 4 GB or more of memory. (Bug #31793)
ORDER BY query using
NULL in the
WHERE clause did not
return correct results.
myisamchk --unpack could corrupt a table that when unpacked has static (fixed-length) row format. (Bug #31277)
When doing a
DELETE on a table
that involved a
MERGE tables and the
JOIN referred to the same table, the
operation could fail reporting
ERROR 1030 (HY000): Got
error 134 from storage engine. This was because scans
on the table contents would change because of rows that had
already been deleted.
Tables with a
GEOMETRY column could be marked
as corrupt if you added a non-
Many nested subqueries in a single query could led to excessive memory consumption and possibly a crash of the server. (Bug #31048)
Server variables could not be set to their current values on Linux platforms. (Bug #31177)
References: See also Bug #6958.
Repeated execution of a query containing a
CASE expression and numerous
OR relations could
crash the server. The root cause of the issue was determined to
be that the internal
SEL_ARG structure was
not properly initialized when created.
Memory corruption could occur due to large index map in
Range checked for each record status reported
SELECT. The problem was based in an incorrectly
calculated length of the buffer used to store a hexadecimal
representation of an index map, which could result in buffer
overrun and stack corruption under some circumstances.
Comparison of a
BIGINT NOT NULL column with a
constant arithmetic expression that evaluated to NULL mistakenly
caused the error Column '...' cannot be
null (error 1048).
ORDER BY query on a view created using a
FEDERATED table as a base table caused the
server to crash.
Referencing within a subquery an alias used in the
SELECT list of the outer query
was incorrectly permitted.
SELECT INTO OUTFILE with 8-bit
ENCLOSED BY characters led to corrupted data
when the data was reloaded using LOAD DATA INFILE. This was
SELECT INTO OUTFILE failed to escape
the 8-bit characters.
SELECT ... GROUP BY
with an assertion if the length of the
BIT column used for the
GROUP BY was not an integer multiple of 8.
A subquery using an
IS NULL check of a column
NOT NULL in a table used in the
FROM clause of the outer query produced an
When casting a string value to an integer, cases where the input
string contained a decimal point and was long enough to overrun
unsigned long long type were not handled
correctly. The position of the decimal point was not taken into
account which resulted in miscalculated numbers and incorrect
truncation to appropriate SQL data type limits.
Some queries using the
NAME_CONST() function failed to
return either a result or an error to the client, causing it to
hang. This was due to the fact that there was no check to insure
that both arguments to this function were constant expressions.
(Bug #27545, Bug #32559)
mysqld sometimes miscalculated the number of
digits required when storing a floating-point number in a
CHAR column. This caused the
value to be truncated, or (when using a debug build) caused the
server to crash.
References: See also Bug #12860.
If the expected precision of an arithmetic expression exceeded the maximum precision supported by MySQL, the precision of the result was reduced by an unpredictable or arbitrary amount, rather than to the maximum precision. In some cases, exceeding the maximum supported precision could also lead to a crash of the server. (Bug #24907)
The options available to the
TABLE statement were also permitted in
OPTIMIZE TABLE and
ANALYZE TABLE statements, but
caused corruption during their execution. These options were
never supported for these statements, and an error is now raised
if you try to apply these options to these statements.
REGEXP operations could cause a
server crash for character sets such as
Now the arguments are converted to
possible, to permit correct results to be produced if the
resulting strings contain only 8-bit characters.
On some 64-bit systems, inserting the largest negative value
BIGINT column resulted in
euc-kr characters having the
second byte in the ranges
[0x61..0x7A] were rejected.
InnoDB does not support
SPATIAL indexes, but could crash when asked
to handle one. Now an error is returned.
ssl-cipher values in option files were not
being read by
mysql-test-run.pl could not run
QUERY statements to target a connection running
SELECT SLEEP() could freeze the server.
FLUSH TABLES WITH
READ LOCK, the server failed to properly detect
write-locked tables when running with low-priority updates,
resulting in a crash or deadlock.
Use of a
BY expression in conjunction with
ROLLUP could cause a server crash.
References: See also Bug #31095.
For transactional tables, an error during a multiple-table
DELETE statement did not roll
back the statement.
NULL values in the value
CREATE TABLE LIKE was treated
libmysqld than by the
Assigning a 65,536-byte string to a
TEXT column (which can hold a
maximum of 65,535 bytes) resulted in truncation without a
warning. Now a truncation warning is generated.
Changing the SQL mode to cause dates with “zero”
parts to be considered invalid (such as
'1000-00-00') could result in indexed and
nonindexed searches returning different results for a column
that contained such dates.
ucs2 does not work as a client character set,
but attempts to use it as such were not rejected. Now
character_set_client cannot be
ucs2. This also affects statements
SET NAMES and
CREATE TABLE ... LIKE statement
that was waiting for a name lock caused a server crash. When the
statement was killed, the server attempted to release locks that
were not held.
The mysql client program now ignores Unicode byte order mark (BOM) characters at the beginning of input files. Previously, it read them and sent them to the server, resulting in a syntax error.
Presence of a BOM does not cause mysql to
change its default character set. To do that, invoke
mysql with an option such as
For comparisons of the form
the comparison is done using
DATETIME values, per the fix for
Bug #27590. However that fix caused any index on
date_col not to be used and
compromised performance. Now the index is used again.
The server crashed in the parser when running out of memory. Memory handling in the parser has been improved to gracefully return an error when out-of-memory conditions occur in the parser. (Bug #31153)
Within a subquery,
handled differently than at the top level, which could result in
incorrect results or a server crash.
(Bug #32036, Bug #32051)
Improper calculation of
expression results could lead to value truncation.
Use of the
cp932 character set with
CAST() in an
BY clause could cause a server crash.
Various test program cleanups were made: 1)
were removed. 2) bug25714 displays an error
message when invoked with incorrect arguments or the
--help option. 3)
mysql_client_test exits cleanly with a proper
Specifying a nonexistent column for an
INSERT DELAYED statement caused a
server crash rather than producing an error.
libmysqld to crash.
MySQL declares a
UNIQUE key as a
PRIMARY key if it doesn't have
NULL columns and is not a partial key, and
PRIMARY key must alway be the first key.
However, in some cases, a nonfirst key could be reported as
PRIMARY, leading to an assert failure by
InnoDB. This is fixed by correcting the key
The optimizer incorrectly optimized conditions out of the
WHERE clause in some queries involving
subqueries and indexed columns.
CREATE ... SELECT ... FROM, where the
resulting table contained indexes, adding
SQL_BUFFER_RESULT to the
SELECT part caused index
corruption in the table.
Denormalized double-precision numbers cannot be handled properly by old MIPS processors. For IRIX, this is now handled by enabling a mode to use a software workaround. (Bug #29085)
A race condition between killing a statement and the thread executing the statement could lead to a situation such that the binary log contained an event indicating that the statement was killed, whereas the statement actually executed to completion. (Bug #27571)
The optimizer made incorrect assumptions about the value of the
is_member value for user-defined functions,
sometimes resulting in incorrect ordering of UDF results.
BLACKHOLE tables caused 100%
CPU use due to locking problems.
If no automatically generated value is successfully inserted,
Zero-padding of exponent values was not the same across platforms. (Bug #12860)
transactional and nontransactional tables caused an assertion