This is a Service Pack release of the MySQL Enterprise Server 5.1.
Replication: When using statement-based or mixed-format replication, the database name was not written to the binary log when executing a
LOAD DATA INFILEstatement. 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
LOAD DATA INFILEstatement is always logged using its fully qualified name when the database to which it belongs is not the current database. (Bug #48297)
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.
References: See also Bug #45261.
If an outer query was invalid, a subquery might not be set up.
EXPLAIN EXTENDEDdid not expect this and caused a crash by trying to dereference improperly set up information. (Bug #48295)
A query containing a view using temporary tables and multiple tables in the
PROCEDURE ANALYSE()caused a server crash.
As a result of this bug fix,
PROCEDURE ANALYSE()is legal only in a top-level
SELECT. (Bug #48293)
References: See also Bug #46184.
An assertion could fail if the optimizer used a
SPATIALindex. (Bug #48258, Bug #47019)
A combination of
GROUP BY WITH ROLLUP,
constjoin type in a query caused a server crash when the optimizer used a temporary table to resolve
DISTINCT. (Bug #48131)
In some cases, using a null microsecond part in a
WHEREcondition (for example,
WHERE date_time_field <= 'YYYY-MM-DD HH:MM:SS.0000') could lead to incorrect results due to improper
DATETIMEcomparison. (Bug #47963)
When a query used a
DATETIMEvalue 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. (Bug #47925)
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_valueflag, which caused an unexpected
NULLvalue to be returned to the caller, resulting in a server crash. (Bug #47780)
InnoDBcould crash when updating spatial values. (Bug #47777)
Incorrect handling of predicates involving
NULLby the range optimizer could lead to an infinite loop during query execution. (Bug #47123)
InnoDBnow ignores negative values supplied by a user for an
AUTO_INCREMENTcolumn when calculating the next value to store in the data dictionary. Setting
AUTO_INCREMENTcolumns to negative values is undefined behavior and this change should bring the behavior of
InnoDBcloser to what users expect. (Bug #46965)
In a replication scenario with
innodb_locks_unsafe_for_binlogenabled 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. (Bug #41756)