MySQL Community Server 5.5.34 has been released

Dear MySQL users,

MySQL Server 5.5.34 is a new version of the 5.5 production release
of the world's most popular open source database. MySQL 5.5.34 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:
http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html

Documentation:
http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

Whitepaper: What's New in MySQL 5.5:
http://www.mysql.com/why-mysql/white-papers/whats-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.
http://mysql.com/products/enterprise/

For information on installing MySQL 5.5.34 on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/5.5/en/installing.html

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:
http://dev.mysql.com/doc/refman/5.5/en/upgrading.html

MySQL Database 5.5.34 is available in source and binary form for a
number of platforms from our download pages at:
http://dev.mysql.com/downloads/mysql/

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:
http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-34.html

Enjoy!

    Changes in MySQL 5.5.34 (2013-09-20)

    Bugs Fixed

           * InnoDB: The row_sel_sec_rec_is_for_clust_rec function would
        incorrectly prepare to compare a NULL column prefix in a
        secondary index with a non-NULL column in a clustered index.
        (Bug #17312846)

      * InnoDB: An incorrect purge would occur when rolling back an
        update to a delete-marked record. (Bug #17302896)

      * InnoDB: InnoDB would rename a user-defined foreign key
        constraint containing the string "_ibfk_" in its name,
        resulting in a duplicate constraint. (Bug #17076737, Bug
        #69693, Bug #17076718, Bug #69707)

      * InnoDB: Rolling back an INSERT after a failed BLOB write would
        result in an assertion failure. The assertion has been
        modified to allow NULL BLOB pointers if an error occurs during
        a BLOB write. (Bug #16971045)

      * InnoDB: A regression introduced with the fix for Bug #11762038
        would cause InnoDB to raise an incorrect error message. The
        message stated that, "InnoDB cannot delete/update rows with
        cascading foreign key constraints that exceed max depth of
        20". The error message would occur when killing connections
        reading from InnoDB tables that did not have foreign key
        constraints. (Bug #16710923)

      * InnoDB: The documentation incorrectly stated that START
        TRANSACTION WITH CONSISTENT SNAPSHOT provides a consistent
        snapshot only if the current isolation level is REPEATABLE
        READ or SERIALIZABLE. START TRANSACTION WITH CONSISTENT
        SNAPSHOT only works with REPEATABLE READ. All other isolation
        levels are ignored. The documentation has been revised and a
        warning is now generated whenever the WITH CONSISTENT SNAPSHOT
        clause is ignored. (Bug #14017206, Bug #65146)

      * InnoDB: The srv_master_thread background thread, which
        monitors server activity and performs activities such as page
        flushing when the server is inactive or in a shutdown state,
        runs on a one second delay loop. srv_master_thread would fail
        to check if the server is in a shutdown state before sleeping.
        (Bug #13417564, Bug #63276)

      * InnoDB: An infinite loop could occur in buf_page_get_gen when
        handling compressed-only pages. (Bug #12560151, Bug #61132)

      * Savepoints could not be used successfully following an
        ER_LOCK_DEADLOCK error (or ER_LOCK_WAIT_TIMEOUT error, if
        innodb_rollback_on_timeout was enabled). (Bug #17356954)
        References: This bug is a regression of Bug #14188793.

      * Within a stored program, comparison of the value of a scalar
        subquery with an IN clause resulted in an error for the first
        execution and raised an assertion for the second execution.
        (Bug #17029399)

      * A race condition in the thread pool plugin could cause status
        variables such as Aborted_connects not to be incremented and
        permitting concurrent kills to happen for the same thread ID.
        (Bug #16959022)

      * The my_strtoll10() function could incorrectly convert some
        long string-format numbers to numeric values and fail to set
        the overflow flag. (Bug #16997513)

      * Within a stored procedure, repeated execution of a prepared
        CREATE TABLE statement for a table with partitions could cause
        a server exit. (Bug #16614004)

      * Deadlocks involving metadata locks and InnoDB deadlocks were
        both reported as an ER_LOCK_DEADLOCK error, but only InnoDB
        deadlocks rolled back the transaction. Now both deadlocks roll
        back the transaction. (Bug #14188793)

      * For queries that accessed an INFORMATION_SCHEMA table in a
        subquery, and attempt to lock a mutex that had already been
        locked could cause a server crash. (Bug #11765744)

      * For failure to create a new thread for the event scheduler,
        event execution, or new connection, no message was written to
        the error log. This could lead to the impression that the
        event scheduler was running normally when it was not. (Bug
        #67191, Bug #14749800, Bug #16865959)

      * mysqldump wrote SET statements as SET OPTION, which failed
        when reloaded because the deprecated OPTION keyword has been
        removed from SET syntax. (Bug #67507, Bug #15844882)

      * If one connection changed its default database and
        simultaneously another connection executed SHOW PROCESSLIST,
        the second connection could access invalid memory when
        attempting to display the first connection's default database.
        memory. (Bug #58198, Bug #11765252)

      * InnoDB deadlock caused transaction rollback but did not
        release metadata locks, blocking concurrent DDL on the
        transaction tables until the connection that got the deadlock
        issued an explicit COMMIT or ROLLBACK. (Bug #69668, Bug
        #17054007)

      * RPM packages did not provide lowercase tags for their
        contents. For example, a server RPM indicated that it provided
        MySQL-server, but not mysql-server. (Bug #69830, Bug
        #17211588)


On Behalf of Oracle MySQL RE Team
Balasubramanian Kandasamy