This is a Service Pack release of the MySQL Enterprise Server 5.1.
Replication: When a session was closed on the master, temporary tables belonging to that session were logged with the wrong database names when either of the following conditions was true:
The length of the name of the database to which the temporary table belonged was greater than the length of the current database name.
The current database was not set.
References: See also Bug #46861, Bug #48297.
When using statement-based or mixed-format replication, the
database name was not written to the binary log when executing a
INFILE statement. This caused problems when the table
being loaded belonged to a database other than the current
database; data could be loaded into the wrong table (if a table
having the same name existed in the current database) or
replication could fail (if no table having that name existed in
the current database). Now a table referenced in a
INFILE statement is always logged using its fully
qualified name when the database to which it belongs is not the
A query containing a view using temporary tables and multiple
tables in the
FROM clause and
PROCEDURE ANALYSE() caused a server crash.
As a result of this bug fix,
ANALYSE() is legal only in a top-level
References: See also Bug #46184.
Incorrect handling of predicates involving
NULL by the range optimizer could lead to an
infinite loop during query execution.
InnoDB could crash when updating
If the first argument to
GeomFromWKB() function was a
geometry value, the function just returned its value. However,
it failed to preserve the argument's
null_value flag, which caused an unexpected
NULL value to be returned to the caller,
resulting in a server crash.
An assertion could fail if the optimizer used a
(Bug #48258, Bug #47019)
A combination of
GROUP BY WITH ROLLUP,
DISTINCT and the
const join type in a query
caused a server crash when the optimizer used a temporary table
In a replication scenario with
enabled on the slave, where rows were changed only on the slave
(not through replication), in some rare cases, many messages of
the following form were written to the slave error log:
InnoDB: Error: unlock row could not find a 4 mode lock
on the record.
In some cases, using a null microsecond part in a
WHERE condition (for example,
date_time_field <= 'YYYY-MM-DD HH:MM:SS.0000')
could lead to incorrect results due to improper
References: See also Bug #45261.
If an outer query was invalid, a subquery might not be set up.
EXPLAIN EXTENDED did not expect
this and caused a crash by trying to dereference improperly set
When a query used a
DATETIME value formatted using
any separator characters other than hyphen
'-') and a
condition matching only the greatest value in an indexed column,
the result was empty if an index range scan was employed.
InnoDB now ignores negative values
supplied by a user for an
column when calculating the next value to store in the data
AUTO_INCREMENT columns to
negative values is undefined behavior and this change should
bring the behavior of
to what users expect.