This is a Service Pack release of the MySQL Enterprise Server 5.1.
When using statement-based or mixed-format replication, the
database name was not written to the binary log when executing a
LOAD DATA 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
statement is always logged using its fully qualified name when
the database to which it belongs is not the current database.
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.
See also Bug#45261.
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
See also Bug#46184.
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
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.
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.
InnoDB could crash when updating
Incorrect handling of predicates involving
NULL by the range optimizer could lead to an
infinite loop during query execution.
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.
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.