* The undocumented --all option for perror is deprecated and will be removed in
MySQL 5.6.
Bugs Fixed:
* InnoDB Storage Engine: A failed CREATE INDEX operation for an InnoDB table
could result in some memory being allocated and not freed. This memory leak
could affect tables created with the ROW_FORMAT=DYNAMIC and
ROW_FORMAT=COMPRESSED settings.
* Partitioning: Auto-increment columns of partitioned tables were checked even
when they were not being written to. In debug builds, this could lead to a
crash of the server.
* Partitioning: The UNIX_TIMESTAMP() function was not treated as a monotonic
function for purposes of partition pruning.
* Replication: If a LOAD DATA INFILE statement—replicated using statement-based
replication—featured a SET clause, the name-value pairs were regenerated
using a method (Item::print()) intended primarily for generating output for
statements such as EXPLAIN EXTENDED, and which cannot be relied on to return
valid SQL. This could in certain cases lead to a crash on the slave.
* To fix this problem, we now name each value in its original, user-supplied
form, and use that to create LOAD DATA INFILE statements for statement-based
replication.
* Previously, an inappropriate error message was produced if a multiple-table
update for an InnoDB table with a clustered primary key would update a table
through multiple aliases, and perform an update that may physically move the
row in at least one of these aliases. Now the error message is: Primary
key/partition key update is not allowed since the table is updated both as
'tbl_name1' and 'tbl_name2'
* ALTER TABLE {MODIFY|CHANGE} ... FIRST did nothing except rename columns if
the old and new versions of the table had exactly the same structure with
respect to column data types. As a result, the mapping of column name to
column data was incorrect. The same thing happened for ALTER TABLE DROP
COLUMN, ADD COLUMN statements intended to produce a new version of table with
exactly the same structure as the old version.
* Incorrect handling of metadata locking for FLUSH TABLES WITH READ LOCK for
statements requiring prelocking caused two problems:
* Execution of any data-changing statement that required prelocking (that is,
involved a stored function or trigger) as part of transaction slowed down
somewhat all subsequent statements in the transaction. Performance in a
transaction that periodically involved such statements gradually degraded
over time.
8e17daa1b6