MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Sunanda Menon Date:September 20 2013 10:17am
Subject:MySQL Community Server 5.6.14 has been released
View as plain text  
Dear MySQL users,

MySQL Server 5.6.14, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.6.14 is
recommended for use on production systems.

For an overview of what's new in MySQL 5.6, please see

     Starting with 5.6.11, Microsoft Windows packages for MySQL 5.6
     are available both as a "full" installer and as a "web" installer.
     The full installer is significantly larger and comes bundled with
     the latest software releases available. This bundle makes it easy
     to download and configure a full server and development suite.

     The web installer doesn't come bundled with any actual products
     and instead relies on download-on-demand to fetch only the
     products you choose to install. This makes the initial download
     much smaller but increases install time as the individual products
     will need to be downloaded.

For information on installing MySQL 5.6.14 on new servers or upgrading
to MySQL 5.6.14 from previous MySQL releases, please see

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

Not all mirror sites may be up to date at this point in time, so if you
can't find this version on some mirror, please try again later or choose
another download site.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc:

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


Changes in MySQL 5.6.14 (2013-09-20)

   Bugs Fixed

      * InnoDB; Partitioning: Following any query on the
        INFORMATION_SCHEMA.PARTITIONS table, InnoDB index statistics
        as shown in the output of statements such as SHOW INDEX were
        updated, even with innodb_stats_on_metadata=OFF. (Bug

      * InnoDB: When logging the delete-marking of a record during
        online ALTER TABLE...ADD PRIMARY KEY, InnoDB writes the
        transaction ID to the log as it was before the deletion or
        delete-marking of the record. When doing this, InnoDB would
        overwrite the DB_TRX_ID field in the original table, which
        could result in locking issues. (Bug #17316731)

      * 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: An assertion would be raised in fil_node_open_file due
        to a missing .ibd file. Instead of asserting, InnoDB should
        return false and the caller of fil_node_open_file should
        handle the return message. (Bug #17305626, Bug #70007)

      * InnoDB: The assertion ut_ad(oldest_lsn <= cur_lsn) in file would fail because the current max LSN would be
        retrieved from the buffer pool before the oldest LSN. (Bug

      * InnoDB: InnoDB memcached add and set operations would perform
        more slowly than SQL INSERT operations. (Bug #17214191)

      * InnoDB: The InnoDB memcached plugin could be initialized to
        insert into an InnoDB table with an INTEGER primary key. (Bug

      * InnoDB: As commented in log0log.h, old_lsn and old_buf_free
        should only be compiled when UNIV_LOG_DEBUG is enabled. (Bug
        #17160270, Bug #69724)

      * 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: A regression introduced in the fix for Bug #14606334
        would cause crashes on startup during crash recovery. (Bug

      * 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: The ha_innobase::clone function would incorrectly
        assert that a thread cannot clone a table handler that is used
        by another thread, and that the original table handler and the
        cloned table handler must belong to the same transaction. The
        incorrect assertions have been removed. (Bug #17001980)

      * InnoDB: When dropping all indexes on a column with multiple
        indexes, InnoDB would fail to block a DROP INDEX operation
        when a foreign key constraint requires an index. (Bug

      * InnoDB: An assertion failure would occur in file on
        ROW_FORMAT=REDUNDANT tables that contained an unexpected but
        valid data directory flag. (Bug #16863098)

      * 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: In debug builds, an assertion failure would occur if
        innodb_log_group_home_dir does not exist. Instead of an
        assertion, InnoDB now aborts with an error message if
        innodb_log_group_home_dir does not exist. (Bug #16691130, Bug

      * InnoDB: For the Barracuda file format and beyond, the
        externally stored prefix would be read even though the prefix
        is already stored locally in memory. (Bug #16569640)

      * InnoDB: When changing the shared tablespace file name using
        innodb_data_file_path and leaving the current log files in
        place, InnoDB would create a new tablespace file and overwrite
        the log files resulting in a mismatch between the data
        dictionary and tables on disk. This bug fix ensures that
        InnoDB does not create a new tablespace if there are
        inconsistent system tablespaces, undo tablespaces, or redo log
        files. (Bug #16418661)

      * InnoDB: Persistent stats would be disabled unnecessarily when
        running in read-only mode. When running in read-only mode,
        fetching stats from disk does not involve any modification of
        on-disk data except for when ANALYZE TABLE is run. This fix
        enables persistent stats for read-only mode. (Bug #16083211)

      * InnoDB: The documentation incorrectly stated that START
        TRANSACTION WITH CONSISTENT SNAPSHOT provides a 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)

      * Replication: When the --relay-log-info-file option was used
        together with --slave-parallel-workers set to a value greater
        than 1, mysqld failed to start. (Bug #17160671)

      * If the mysql_real_connect() C API function failed, it could
        leak memory. (Bug #17337684)

      * 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.

      * Full-text search on InnoDB tables failed on searches that used
        the + boolean operator. (Bug #17280122)

      * For single-threaded workloads, the optimizer recognizes some
        special cases for which it can avoid function calls and
        enhance performance. (Bug #17234723)

      * SELECT * from performance_schema.events_statements_current
        could raise an assertion due to a race condition under load.
        (Bug #17164720)

      * AES_ENCRYPT() and AES_DECRYPT() failed to work correctly when
        MySQL was built with an AES_KEY_LENGTH value of 192 or 256.
        (Bug #17170207)

      * InnoDB full-text searches failed in databases whose names
        began with a digit. (Bug #17161372)

      * A successful connection failed to reset the per-IP address
        counter used to count successive connection failures. This
        could possibly cause a host to be blocked, when the
        max_connect_errors limit was reached. (Bug #17156507)

      * Under load, truncating the accounts Performance Schema table
        could cause a server exit. (Bug #17084615)

      * With the thread pool plugin enabled and SSL in use, an error
        in one connection might affect other connections, causing them
        to experience a lost connection. (Bug #17087862)

      * 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)

      * Excessive memory consumption was observed for multiple
        execution of a stored procedure under these circumstances: 1)
        The stored procedure had an SQL statement that failed during
        validation. 2) The stored procedure had an SQL statement that
        required repreparation. (Bug #16857395)

      * For partitioned tables, queries could return different results
        depending on whether Index Merge was used. (Bug #16862316)

      * For some statements, memory leaks could result when the
        optimizer removed unneeded subquery clauses. (Bug #16807641)
        References: This bug is a regression of Bug #15875919.

      * Password rewriting in the general query log now also applies
        to prepared statements. (Bug #16732621)

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

     * For debug builds, when the optimizer removed an Item_ref
        pointing to a subquery, it caused a server exit. (Bug
        References: This bug is a regression of Bug #16318585.

      * If the primary key for the mysql.proc system table was removed
        (an unsupported and not-recommended operation), the server
        exited for subsequent stored procedure invocation. Similar
        problems could occur for other system tables. Now an error
        occurs instead. (Bug #16373054)

      * 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)

      * Metadata returned for a prepared SELECT statement that had
        outer joins could indicate that columns containing NULL values
        were NOT NULL. (Bug #12818811)

      * 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)

      * For better robustness against stack overflow, the server now
        accounts for the size of the guard area when making thread
        stack size requests. (Bug #35019, Bug #11748074)

      * The libmysql.dll library was missing several symbols: my_init,
        mysql_client_find_plugin, mysql_client_register_plugin,
        mysql_load_plugin, mysql_load_plugin_v, mysql_options4, and
        mysql_plugin_options. (Bug #69204, Bug #16797982, Bug #62394)

      * 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)

      * Full-text search on InnoDB tables failed on searches for words
        containing apostrophes when using boolean operators. (Bug
        #69932, Bug #17276125)

      * 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

  On Behalf of the MySQL/ORACLE RE Team,

  Sunanda Menon

MySQL Community Server 5.6.14 has been releasedSunanda Menon20 Sep