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 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
LOAD DATA INFILE statement 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.
SUM() artificially increased the precision of a
DECIMAL argument, which was truncated when a temporary table was created to hold the results. (Bug #48370)
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 up information. (Bug #48295)
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,
PROCEDURE ANALYSE() is legal only in a top-level
SELECT. (Bug #48293)
References: See also Bug #46184.
Error handling was missing for
SELECT statements containing subqueries in the
WHERE clause and that assigned a
SELECT result to a user variable. The server could crash as a result. (Bug #48291)
An assertion could fail if the optimizer used a
SPATIAL index. (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 to resolve
DISTINCT. (Bug #48131)
In some cases, using a null microsecond part in a
WHERE condition (for example,
WHERE date_time_field <= 'YYYY-MM-DD HH:MM:SS.0000') could lead to incorrect results due to improper
DATETIME comparison. (Bug #47963)
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. (Bug #47925)
During cleanup of a stored procedure's internal structures, the flag to ignore the errors for
INSERT IGNORE or
UPDATE IGNORE was not cleaned up, which could result in a server crash. (Bug #47788)
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. (Bug #47780)
InnoDB could crash when updating spatial values. (Bug #47777)
Incorrect handling of predicates involving
NULL by the range optimizer could lead to an infinite loop during query execution. (Bug #47123)
InnoDB now ignores negative values supplied by a user for an
AUTO_INCREMENT column when calculating the next value to store in the data dictionary. Setting
AUTO_INCREMENT columns to negative values is undefined behavior and this change should bring the behavior of
InnoDB closer to what users expect. (Bug #46965)
In a replication scenario with
innodb_locks_unsafe_for_binlog 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. (Bug #41756)