MySQL Community Server 5.5.37 has been released

Dear MySQL users,

MySQL Server 5.5.37 is a new version of the 5.5 production release
of the world's most popular open source database. MySQL 5.5.37 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.37 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.37 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-37.html

Enjoy!

Changes in MySQL 5.5.37 (2014-03-27)

    Functionality Added or Changed

      * On Solaris, mysql_config --libs now includes
        -R/path/to/library so that libraries can be found at runtime.
        (Bug #18235669)

    Bugs Fixed

      * InnoDB: A regression introduced by Bug #14329288 would result
        in a performance degradation when a compressed table does not
        fit into memory. (Bug #18124788, Bug #71436)

      * InnoDB: The maximum value for innodb_thread_sleep_delay is now
        1000000 microseconds. The previous maximum value (4294967295
        microseconds on 32-bit and 18446744073709551615 microseconds
        on 64-bit) was unnecessarily large. Because the maximum value
        of innodb_thread_sleep_delay is limited by the value set for
        innodb_adaptive_max_sleep_delay (when set to a non-zero
        value), the maximum value for innodb_thread_sleep_delay is now
        the same as the maximum value for
        innodb_adaptive_max_sleep_delay. (Bug #18117322)

      * InnoDB: In debug builds, creating a unique index on a binary
        column, with input data containing duplicate keys, would cause
        an assertion. (Bug #18010711)

      * InnoDB: InnoDB would fail to start when innodb_data_file_path
        specified the data file size in kilobytes by appending K to
        the size value. (Bug #16287752)

      * InnoDB: An insert buffer merge would cause an assertion error
        due to incorrectly handled ownership information for
        externally stored BLOBs.
        InnoDB: Assertion failure in thread thread_num in file ibuf0ibuf.cc line 4080
        InnoDB: Failing assertion: rec_get_deleted_flag(rec, page_is_comp(page))
        (Bug #14668683)

      * InnoDB: Decreasing the auto_increment_increment value would
        have no affect on the next auto-increment value. (Bug
        #14049391, Bug #65225)

      * Replication: The server did not handle correctly the insertion
        of a row larger than 4 GB when using row-based replication.
        (Bug #17081415)

      * Replication: When using row-based replication, an additional
        auto-increment column on the slave version of a table was not
        updated correctly; a zero was inserted instead. (Bug
        #17066269, Bug #69680)

      * Replication: Statements involving the Performance Schema
        tables should not be written to the binary log, because the
        content of these tables is applicable only to a given MySQL
        Server instance, and may differ greatly between different
        servers in a replication topology. The database administrator
        should be able to configure (INSERT, UPDATE, or DELETE) or
        flush (TRUNCATE TABLE) performance schema tables on a single
        server without affecting others. However, when replicating
        from a MySQL 5.5 master to a MySQL 5.5 or later slave,
        warnings about unsafe statements updating Performance Schema
        tables were elevated to errors. For MySQL 5.6 and later
        slaves, this prevented the simultaneous use of
        performance_schema and GTIDs (see Replication with Global
        Transaction Identifiers
        (http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html),
        in the MySQL 5.6 Manual).
        This fix causes all updates on tables in the
        performance_schema database to be filtered on the master and
        not replicated, regardless of the type of logging that is in
        effect. Prior to this fix, statements using were handled by
        being marked as unsafe for replication, which caused warnings
        during execution; the statements were nonetheless written to
        the binary log, regardless of the logging format in effect.
        Existing replication behavior for tables in the
        INFORMATION_SCHEMA database is not changed by this fix.
        For more information, see MySQL Performance Schema
        (http://dev.mysql.com/doc/refman/5.5/en/performance-schema.html).
        (Bug #16814264)
        References: See also Bug #14741537, Bug #18259193.

      * Compilation failed if MySQL was configured with CFLAGS set to
        include a -Werror option with an argument. (Bug #18173037)

      * A shared libmysqld embedded server library was not built on
        Linux. (Bug #18123048, Bug #16430656, Bug #68559)

      * While printing the server version, the mysql client did not
        check for buffer overflow in a string variable. (Bug
        #18186103)

      * Contraction information in a collation could be mishandled,
        resulting in incorrect decisions about whether a character is
        part of a contraction, and miscalculation of contraction
        weights. (Bug #17760379)

      * DROP TRIGGER succeeded even with the read_only system variable
        enabled. (Bug #17503460)

      * Updating the Performance Schema setup_instruments table on a
        replication master caused a slave to exit. (Bug #14539290)

      * Due to a race condition, it was possible for two threads to
        end up with the same query ID for different queries. (Bug
        #58785, Bug #11765785)

      * When run by root, mysqld --help --verbose exited with a
        nonzero error code after displaying the help message. (Bug
        #70058, Bug #17324415)

      * MySQL client programs from a Community Edition distribution
        could not connect using SSL to a MySQL server from an
        Enterprise Edition. This was due to a difference in
        certificate handling by yaSSL and OpenSSL (used for Community
        and Enterprise, respectively). OpenSSL expected a blank
        certificate to be sent when not all of the --ssl-ca,
        --ssl-cert, and --ssl-key options were specified, and yaSSL
        did not do so. To resolve this, yaSSL has been modified to
        send a blank certificate when an option is missing. (Bug
        #68788, Bug #16715064)

      * A deadlock error occurring during subquery execution could
        cause an assertion to be raised. (Bug #69969, Bug #17307201)

      * The Performance Schema stage/sql/Waiting to get readlock
        instrument is no longer used and has been removed. (Bug
        #71298, Bug #18035404)

      * For system variables that take a string value, SET statements
        permitted an unquoted value, but values that contained dots
        were parsed incorrectly and only part of the value was
        assigned. For example, SET GLOBAL slow_query_log_file =
        my_slow.log assigned the value my_slow. Now such values must
        be quoted or an error occurs. (Bug #69703, Bug #17075846)


On Behalf of Oracle/MySQL RE Team,
Balasubramanian Kandasamy