MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.5.29 has been released
Posted by: Jocelyn Ramilison
Date: December 21, 2012 02:29PM

Dear MySQL users,

MySQL 5.5.29 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.29 is recommended
for use on production systems.

MySQL 5.5 includes several high-impact enhancements to improve the
performance and scalability of the MySQL Database, taking advantage of
the latest multi-CPU and multi-core hardware and operating systems. In
addition, with release 5.5, InnoDB is now the default storage engine for
the MySQL Database, delivering ACID transactions, referential integrity
and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

    - Significantly improved performance on Windows, with various
      Windows specific features and improvements
    - Higher availability, with new semi-synchronous replication and
      Replication Heartbeat
    - Improved usability, with Improved index and table partitioning,
      SIGNAL/RESIGNAL support and enhanced diagnostics, including a new
      Performance Schema monitoring capability.

For a more complete look at what's new in MySQL 5.5, please see the
following resources:

MySQL 5.5 is GA, Interview with Tomas Ulin:


Whitepaper: What's New in MySQL 5.5:

If you are running a MySQL production level system, we would like to
direct your attention to MySQL Enterprise Edition, which includes the
most comprehensive set of MySQL production, backup, monitoring,
modeling, development, and administration tools so businesses can
achieve the highest levels of MySQL performance, security and uptime.

For information on installing MySQL 5.5.29 on new servers, please see
the MySQL installation documentation at

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:

MySQL Database 5.5.29 is available in source and binary form for a
number of platforms from our download pages at:

The following section lists the changes in the MySQL source code since
the previous released version of MySQL 5.5. It may also be viewed
online at:


Changes in MySQL 5.5.29 (21-December-2012)

 Functionality Added or Changed

   * The SHOW AUTHORS and SHOW CONTRIBUTORS statements are now
     deprecated in MySQL 5.5 and have been removed in MySQL 5.6.

 Bugs Fixed

   * Performance: InnoDB: The timing values for low-level InnoDB
     read operations were adjusted for better performance with fast
     storage devices, such as SSD
     ). This enhancement primarily affects read operations for BLOB
     columns in compressed
     pression) tables. (Bug #13702112, Bug #64258)

   * Important Change: InnoDB: A DML
     ) statement using the index merge access method could lock
     many rows from the table, even when those rows were not part
     of the final result set. This fix reduces the excessive
     king) by releasing the locks of unmatched rows. This
     optimization affects only transactions with isolation level
     equal to or less strict than READ COMMITTED; it does not apply
     to transactions using REPEATABLE READ or SERIALIZABLE
     isolation level. (Bug #14226171)

   * InnoDB: An online DDL operation for an InnoDB table
     incorrectly reported an empty value ('') instead of the
     correct key value when it reported a duplicate key error for a
     unique index using an index prefix. (Bug #14729221)

   * InnoDB: If a CREATE TABLE statement failed due to a disk full
     error, some memory allocated during the operation was not
     freed properly. (Bug #14708715)

   * InnoDB: With the innodb_file_per_table setting enabled, a DROP
     TABLE operation could cause a crash, due to a race condition
     that depended on the timing of pending I/O requests. (Bug
     #14594600, Bug #66718)

   * InnoDB: If the server crashed at the specific point when a
     change buffer
     nge_buffer) entry was being merged into a buffer pool page,
     the transaction log and the change buffer were left in an
     inconsistent state. After a restart, MySQL could crash after
     reading the corresponding secondary index page. The problem
     was more likely to occur in MySQL 5.5 or later, where the
     original insert buffering
     ert_buffering) mechanism was generalized to cover other
     operations. (Bug #14636528, Bug #66819, Bug #58571, Bug
     #61104, Bug #65443)

   * InnoDB: Inserting data of varying record lengths into an
     InnoDB table that used compression
     pression) could cause the server to halt with an error. (Bug
     #14554000, Bug #13523839, Bug #63815, Bug #12845774, Bug
     #61456, Bug #12595091, Bug #61208)

   * InnoDB: If a table was defined with an index key length very
     close to the upper length limit of 3072, a query against that
     table could cause a serious error. (Bug #14500557, Bug #66413)

   * InnoDB: When an auto-increment column used a FLOAT or DOUBLE
     data type, if the auto-increment value became very large
     (larger than the maximum unsigned long long value), subsequent
     inserts could fail or cause the server to halt. (Bug
     #14145950, Bug #55071)

   * InnoDB: If a transaction was started with a consistent
     snapshot, then new indexes were added to the table while the
     transaction was in progress, a subsequent UPDATE statement
     could incorrectly encounter the error:
     HA_ERR_TABLE_DEF_CHANGED: insufficient history for index
     This issue could cause an assertion error in debug builds.
     (Bug #14036214)

   * InnoDB: The error message was improved for the case where an
     UPDATE failed because the row included several BLOB values
     greater than 768 bytes each, causing the size of a row to
     exceed half the page size
     e_size). The old message, was misleading; it suggested using
     BLOBs, when the 768-byte prefix for each BLOB column was the
     cause of the limit error:
     Error Code 1118: Row size too large. The maximum row size for
     the used table type, not counting BLOBs, is 8126. You have to
     change some columns to TEXT or BLOBs
     A workaround for the problem was to create the table with the
     now suggested in the message. (Bug #13453036, Bug #63507)

   * InnoDB: In rare circumstances, MySQL could apply InnoDB undo
     o) records out of order during a ROLLBACK
     lback) of an operation that modified a BLOB column. This issue
     could cause an assertion error in debug builds:
     (Bug #13249921)

   * Replication: Updates writing user variables whose values were
     never set on a slave while using --replicate-ignore-table
     could cause the slave to fail. (Bug #14597605)
     References: This bug was introduced by Bug #14275000.

   * Replication: Backtick (`) characters were not always handled
     correctly in internally generated SQL statements, which could
     sometimes lead to errors on the slave. (Bug #14548159)

   * Replication: Following an insert into a nontransactional table
     that failed due to insufficient disk space, the server did not
     properly clean up all pending events, leading to an assert or
     possibly to other errors. (Bug #11750014)

   * Very long database names in queries could cause the server to
     exit. (Bug #15912213)

   * Within a stored procedure, executing a multiple-table DELETE
     statement that used a very long table alias could cause the
     server to exit. (Bug #15954896)

   * Very long table aliases in queries could cause the server to
     exit. (Bug #15948123)

   * Attempting to create an auto-increment
     o_increment) column in an InnoDB table with a NULL type
     attribute could cause a serious error. (Bug #14758479)

   * A DELETE statement for an InnoDB table could write incorrect
     transaction metadata into a record, causing the server to halt
     with an error. To work around this issue, reduce the specified
     length of the primary key to less than 1K bytes. (Bug

   * Repeated execution of a query containing a subquery that used
     MAX() could result in increasing memory consumption. (Bug

   * USE dbname could fail with Unknown database when dbname
     contained multiple backtick (`) characters. (Bug #14645196)

   * The script that converts GNU configure options to
     CMake equivalents generated erroneous output for the
     --with-client-ldflags and --with-mysqld-ldflags options. It
     now ignores those options. (Bug #14593123)

   * SHOW PROFILE could be used to cause excessive server memory
     consumption. (Bug #14629232)

   * The thread cache implementation worked in LIFO rather than
     FIFO fashion and could result in a thread being denied service
     (although this was a remote possibility). (Bug #14621627)

   * Within a stored program, memory allocated to hold condition
     information was not released until program exit, leading to
     excessive memory use. (Bug #14640599)

   * Improper memory cleanup could cause the server to exit. (Bug

   * Granting or revoking the PROXY privilege caused the server to
     exit if the server was started with --skip-name-resolve. (Bug

   * CREATE USER and DROP USER could fail to flush the privileges,
     requiring FLUSH PRIVILEGES to be used explicitly. (Bug

   * Access to INFORMATION_SCHEMA tables through a view could leak
     memory. (Bug #13734987)

   * A memory leak could occur for queries containing a subquery
     that used GROUP BY on an outer column. (Bug #13724099)

   * On Microsoft Windows with CMake 2.6, the build process would
     not stop if the create_initial_db step failed. (Bug #13713525)

   * The test in mysqld_safe for the presence of the --plugin_dir
     option and assignment of a default value to it were performed
     before the actual argument parsing took place. (Bug #13548161)

   * CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had
     a corrupt key (.MYI) file. Now the server produces an error.
     (Bug #13556441)

   * Improper memory cleanup could cause the server to exit. (Bug

   * A memory leak occurred due to failure to clean up after
     QUICK_INDEX_MERGE_SELECT/Unique. (Bug #12694872, Bug

   * The number of connection errors from a given host as counted
     by the server was periodically reset, with the result that
     max_connect_errors was never reached and invalid hosts were
     never blocked from trying to connect. (Bug #11753779)
     References: See also Bug #38247, Bug #43006, Bug #45584, Bug

   * During optimization, ZEROFILL values may be converted to
     string constants. However, CASE expressions did not handle
     switching data types after the planning stage, leading to CASE
     finding a null pointer instead of its argument. (Bug #57135,
     Bug #11764313)

   * In debug builds, an InnoDB assertion was overly aggressive
     about prohibiting an open range. (Bug #66513, Bug #14547952)

   * On Windows, the Perl version of mysql_install_db created
     system tables in the mysql database that were not populated
     properly. (Bug #65584, Bug #14181049)

   * mysqld_safe ignored the value of the UMASK environment
     variable, leading to behavior different from mysqld with
     respect to the access mode of created files. Now mysqld_safe
     (and mysqld_multi) attempt to approximate the same behavior as
     mysqld. (Bug #57406, Bug #11764559)

   * LAST_INSERT_ID(expr) did not work for expr values greater than
     the largest signed BIGINT value. (Bug #20964, Bug #11745891)

On behalf of the MySQL/ORACLE Build Team

Hery Ramilison

Options: ReplyQuote

Written By
MySQL Community Server 5.5.29 has been released
December 21, 2012 02:29PM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.