Changes in MySQL Enterprise 5.1.40sp1 [QSP] (2009-11-25)

This is a Service Pack release of the MySQL Enterprise Server 5.1.

Bugs Fixed

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.

(Bug #48216)

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 DATE or
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)

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)