MySQL 5.5.15 GA Released

MySQL databaseMySQL 5.5.15 GA has been released in 28 July 2011.

Functionality Added or Changed

  • 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. (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 crash of the server. (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, we now name each value in its original, user-supplied form, and use that to create LOAD DATA INFILEstatements for statement-based replication. (Bug #11902767, Bug #60580)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)
  • 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)See also Bug #11764529.
  • 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. (Bug #61493, Bug #12652385)
  • Incorrect handling of metadata locking for FLUSH TABLES WITH READ LOCKfor 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.

    (Bug #61401, Bug #12641342)

  • The fractional part of the “Queries per second” value in MySQL status output could be displayed incorrectly. (Bug #61205, Bug #12565712)
  • 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)
  • For unknown users, the native password plugin reported incorrectly that no password had been specified even when it had. (Bug #59792, Bug #11766641)
  • For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption. (Bug #57323, Bug #11764487)
  • In debug builds, Field_new_decimal::store_value() was subject to buffer overflows. (Bug #55436, Bug #11762799)
  • 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)

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.