MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.5.30 has been released
Posted by: Sunanda Menon
Date: February 05, 2013 09:39PM

Dear MySQL users,

MySQL 5.5.30 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.30 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.30 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.30 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.30 (5 Feb, 2013)

   Known limitations of this release:

   On Microsoft Windows, when using the MySQL Installer to install
   MySQL Server 5.5.30 on a host with an existing MySQL Server of a
   different version (such as 5.6.10), that also has a different
   license (community versus commercial), you must first update the
   license type of the existing MySQL Server. Otherwise, MySQL
   Installer will remove MySQL Server(s) with different licenses from
   the one you chose with MySQL Server 5.5.30.

   On Microsoft Windows 8, updating a community release to a
   commercial release requires you to manually restart the MySQL
   service after the update.

   Functionality Added or Changed

      * InnoDB: The innodb_print_all_deadlocks configuration option
       from MySQL 5.6 was backported to MySQL 5.5. This option
       records each deadlock
       condition in the MySQL error log, allowing easier
       troubleshooting if frequent deadlocks point to application
       coding issues. (Bug #14515889)

     * In RPM packages built for Unbreakable Linux Network, now has a version number. (Bug #15972480)

   Bugs Fixed

     * InnoDB; Performance: Some data structures related to undo
       logging could be initialized unnecessarily during a query,
       although they were only needed under specific conditions. (Bug

     * InnoDB; Performance: Optimized read operations for compressed
       tables by skipping redundant tests. The check for whether any
       related changes needed to be merged from the insert buffer
       l) was being called more often than necessary. (Bug #14329288,
       Bug #65886)

     * InnoDB; Performance: Immediately after a table was created,
       queries against it would not use loose index scans
       . The issue went away following an ALTER TABLE on the table.
       The fix improves the accuracy of the index statistics
       html) gathered when the table is first created, and prevents
       the query plan from being changed by the ALTER TABLE
       statement. (Bug #14200010)

     * InnoDB; Partitioning: Previously, when attempting to optimize
       one or more partitions of a partitioned table that used a
       storage engine that does not support partition-level OPTIMIZE,
       such as InnoDB, MySQL reported Table does not support
       optimize, doing recreate + analyze instead, then re-created
       the entire table, but did not actually analyze it. Now in such
       cases, the warning message is, Table does not support optimize
       on partitions. All partitions will be rebuilt and analyzed. In
       addition, the entire table is analyzed after first being
       rebuilt. (Bug #11751825)

     * InnoDB: On systems that cannot handle unaligned memory access,
       depending on the stack frame alignment, a SIGBUS error could
       occur during startup. This issue was observed on Solaris
       64-bit systems. (Bug #16021177)

     * InnoDB: The status variable
       Innodb_buffer_pool_read_ahead_evicted could show an inaccurate
       value, higher than expected, because some pages in the buffer
       were incorrectly considered as being brought in by read-ahead
       requests. (Bug #15859402, Bug #67476)

     * InnoDB: Creating an index on a CHAR column could fail for a
       table with a character set with varying length, such as UTF-8,
       if the table was created with the ROW_FORMAT=REDUNDANT clause.
       (Bug #15874001)

     * InnoDB: The server could halt with an assertion error while
       creating an index:
       InnoDB: Assertion failure in thread thread_num in file
       line 465
       This issue affected tables with a combination of
       ROW_FORMAT=REDUNDANT off-page columns
       tml), and an index on a column prefix
       l). (Bug #14753402)

     * InnoDB: If the server crashed at a precise moment during an
       ALTER TABLE operation that rebuilt the clustered index
       tml) for an InnoDB table, the original table could be
       inaccessible afterward. An example of such an operation is
       ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original
       table if the server halts during this operation. You might
       still need to rename the .ibd file manually to restore the
       original table contents: in MySQL 5.6 and higher, rename from
       #sql-ib$new_table_id.ibd to table_name.ibd within the database
       directory; prior to MySQL 5.6, the temporary file to rename is
       table_name#1 or #2. (Bug #14669848)

     * InnoDB: An error at the filesystem level, such as too many
       open files, could cause an unhandled error during an ALTER
       TABLE operation. The error could be accompanied by Valgrind
       warnings, and by this assertion message:
       Assertion `! is_set()' failed.
       mysqld got signal 6 ;
       (Bug #14628410, Bug #16000909)

     * InnoDB: A RENAME TABLE statement could stall for several
       minutes before timing out. This issue could occurred for a
       table using compression
       , with change buffering
       html) enabled. (Bug #14556349)

     * InnoDB: During shutdown, with the innodb_purge_threads
       configuration option set greater than 1, the server could halt
       prematurely with this error:
       mysqld got signal 11
       A workaround was to increase innodb_log_file_size and set
       innodb_purge_threads=1. The fix was backported to MySQL 5.5
       and 5.1, although those versions do not have the
       innodb_purge_threads configuration option so the error was
       unlikely to occur. (Bug #14234028)

     * InnoDB: If the value of innodb_force_recovery was less than 6,
       opening a corrupted table might loop forever if a corrupted
       page was read when calculating statistics for the table.
       Information about the corrupted page was written repeatedly to
       the error log, possibly causing a disk space issue. The fix
       causes the server to halt after a fixed number of failed
       attempts to read the page. To troubleshoot such a corruption
       issue, set innodb_force_recovery=6 and restart. (Bug
       #14147491, Bug #65469)

     * InnoDB: The value of the innodb_version variable was not
       updated consistently for all server releases for the InnoDB
       Plugin in MySQL 5.1, and the integrated InnoDB component in
       MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server
       development cycles are fully integrated and synchronized, now
       the value returned by the innodb_version variable is the same
       as for the version variable. (Bug #13463493, Bug #63435)

     * Partitioning: Concurrent ALTER TABLE ... REBUILD PARTITION
       operations could interfere with one another, even when not
       running against the same table, because they both used global
       memory for storage. Now each partition rebuild operation
       stores intermediate data in memory that is local to that
       process. (Bug #14589559, Bug #66645)

     * Partitioning: Inserting any number of rows into an ARCHIVE
       table that used more than 1000 partitions and then attempting
        to drop the table caused the MySQL Server to fail. (Bug
       #13819630, Bug #64580)

     * Replication: After dropping a column from the slave's version
       of a table, then altering the same column of this table on the
       master (so that a type conversion would have been required had
       the column not been droppped on the slave), inserts into this
       table caused replication to fail. (Bug #15888454)

     * Replication: When a binary log is replayed on a server (for
       example, by executing a command like mysqlbinlog binlog.000001
       | mysql), it sets a pseudo-slave mode on the client connection
       used, so that the server can read binlog and apply binary log
       events correctly. However, the pseudo-slave mode was not
       disabled after the binary log dump was read, which caused
       unexpected filtering rules to be applied to SQL statements
       subsequently executed on the same connection. (Bug #15891524)

     * Replication: When using statement-based replication, and where
       the master and the slave used table schemas having different
       AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT
       values logged for a given table on the master could be applied
       to the wrong table on the slave. (Bug #12669186)

     * Replication: Repeated execution of CHANGE MASTER TO statements
       using invalid MASTER_LOG_POS values could lead to errors and
       possibly a crash on the slave. Now in such cases, the
       statement fails with a clear error message. (Bug #11764602,
       Bug #57454)

     * Replication: If the disk becomes full while writing to the
       binary log, the server hangs until space is freed up manually.
       It was possible after this was done for the MySQL server to
       fail, due to an internal status value being set when not
       needed. Now in such cases, rather than trying to set this
       status, a warning is written in the error log instead. (Bug
       #11753923, Bug #45449)

      * Microsoft Windows: Dynamic file names (with colons) are no
       longer allowed. Static file names using the Alternate Data
       Stream (ADS) NTFS functionality of Microsoft Windows may
       continue to be used. (Bug #11761752)

     * Directory name manipulation could result in stack overflow on
       Mac OS X and Windows. (Bug #16066243)

     * Joins of exactly 32 tables and containing a HAVING clause
       returned an empty result. (Bug #15972635)

     * A buffer-handling problem in yaSSL was fixed. (Bug #15965288)

     * A mysys library string-formatting routine could mishandle
       width specifiers. (Bug #15960005)

     * In certain cases, UpdateXML() could return NULL incorrectly.
       (Bug #15948580)
       References: See also Bug #13007062.

     * Metadata locking and table definition cache routines did not
       always check length of names passed to them. (Bug #15954872)

     * XA START had a race condition that could cause a server crash.
       (Bug #14729757)

     * Enabling the query cache during high client contention could
       cause the server to exit. (Bug #14727815)

     * There was a performance regression for queries using SELECT
       ... INTO user variables and a WHERE condition on one or more
       of the variables in the INTO list. (Bug #14664077)
       References: This bug was introduced by Bug #12408412.

     * The server sometimes failed to respect
       MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug

     * Output generated with mysqldump --routines could produce
       syntax errors when reloaded. (Bug #14463669)

     * With the thread pool plugin installed, a workload consisting
       of concurrent KILL statements and ping queries caused the
       server to exit. (Bug #14458232, Bug #14458002)

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

     * Passing an unknown time zone specification to CONVERT_TZ()
       resulted in a memory leak. (Bug #12347040)

     * For dumps of the mysql database, mysqldump skipped the event
       table unless the --events option was given. To skip this table
       if that is desired, use the --ignore-table option instead (Bug
       #55587, Bug #11762933)

     * For MEMORY tables with HASH indexes, DELETE sometimes failed
       to delete all applicable rows. (Bug #51763, Bug #11759445)

     * The mysql client could mishandle the delimiter command if it
       occurred on a line during which mysql was looking for the end
       of a quoted string. (Bug #64135, Bug #13639125)

     * mysqld_safe used the nonportable -e test construct. (Bug
       #67976, Bug #16046140)

     * Configuring the server with
       performance_schema_events_waits_history_size=0 and
       performance_schema_events_waits_history_long_size=0 could
       cause a Performance Schema segmentation fault. (Bug #68008,
       Bug #16060864)

      * DECIMAL multiplication operations could produce significant
       inaccuracy. (Bug #45860, Bug #11754279)

     * For subqueries executing using a filesort, the optimizer could
       produce an incorrect result containing wrong rows. (Bug
       #66845, Bug #14636211)
       References: See also Bug #12667154.

     * UNION type conversion could incorrectly turn unsigned values
       into signed values. (Bug #49003, Bug #11757005)

     * During the startup process, mysqld could incorrectly remove
       the PID file of an already running mysqld. (Bug #23790, Bug
       References: See also Bug #14726272.

On behalf of the MySQL/ORACLE Build Team,

Sunanda Menon

Options: ReplyQuote

Written By
MySQL Community Server 5.5.30 has been released
February 05, 2013 09:39PM

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.