The undocumented --all option for perror is deprecated and will be removed in MySQL 5.6.

Performance; InnoDB: The DROP TABLE command for an InnoDB table could be very slow, in a configuration with a combination of table compression, partitioning, and a large buffer pool. (Bug #12635227, Bug #61188)

InnoDB: A failed CREATE INDEX operation for an InnoDB table could result in some memory being allocated but not freed. This memory leak could affect tables created with the ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED setting. (Bug #12699505)

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 server crash. (Bug #11765667, Bug #58655)

Partitioning: The UNIX_TIMESTAMP() function was not treated as a monotonic function for purposes of partition pruning. (Bug #11746819, Bug #28928)

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, the server now names each value in its original, user-supplied form, and uses that to create LOAD DATA INFILE statements for statement-based replication. (Bug #60580, Bug #11902767)

References: See also Bug #34283, Bug #11752526, Bug #43746.

Compiling the server with maintainer mode enabled failed for gcc 4.6 or higher. (Bug #12727287)

The option-parsing code for empty strings leaked memory. (Bug #12589928)

mysql_list_fields() returned incorrect character set information for character columns of views. (Bug #12337762)

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 permitted since the table is updated both as 'tbl_name1' and 'tbl_name2' (Bug #11882110)

References: See also Bug #11764529.

In debug builds, Field_new_decimal::store_value() was subject to buffer overflows. (Bug #55436, Bug #11762799)

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. (Bug #60987, Bug #12403662)

Incorrect handling of metadata locking for FLUSH TABLES WITH READ LOCK for statements requiring prelocking caused two problems:

(Bug #61401, Bug #12641342)

For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption. (Bug #57323, Bug #11764487)

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 the table with exactly the same structure as the old version. (Bug #61493, Bug #12652385)

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 (Bug #47870, Bug #11756013)

The fractional part of the “Queries per second” value could be displayed incorrectly in MySQL status output (for example, in the output from mysqladmin status or the mysql STATUS command). (Bug #61205, Bug #12565712)

For unknown users, the native password plugin reported incorrectly that no password had been specified even when it had. (Bug #59792, Bug #11766641)