Changes 5.5.15:

* 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.

0 files changed, 0 insertions, 0 deletions