# 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.- Execution of any data-changing statement that required prelocking as part of transaction prevented a concurrent FLUSH TABLES WITH READ LOCK from proceeding until the end of transaction rather than at the end of the particular statement.* The fractional part of the “Queries per second” value in MySQL status output could be displayed incorrectly.* LOAD DATA INFILE incorrectly parsed relative data file path names that ascended more than three levels in the file system and as a consequence was unable to find the file.* For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption.* In debug builds, Field_new_decimal::store_value() was subject to buffer overflows.* A race condition between loading a stored routine using the name qualified by the database name and dropping that database resulted in a spurious error message: The table mysql.proc is missing, corrupt, or contains bad data