MySQL Community Server 5.6.20 has been released

[Karen Langford]

Dear MySQL users,

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

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

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

    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.20 on new servers or upgrading
to MySQL 5.6.20 from previous MySQL releases, please see

http://dev.mysql.com/doc/refman/5.6/en/installing.html

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

http://dev.mysql.com/downloads/

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:

https://wikis.oracle.com/display/mysql/Contributing

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

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html

Enjoy!

Changes in MySQL 5.6.20 (2014-07-31)

   Security Notes

     * Security Fix: The linked OpenSSL library for the MySQL 5.6
       Commercial Server has been updated from version 1.0.1g to
       version 1.0.1h. Versions of OpenSSL prior to and including
       1.0.1g are reported to be vulnerable to CVE-2014-0224
       (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224).
       This change does not affect the Oracle-produced MySQL
       Community build of MySQL Server 5.6, which uses the yaSSL
       library instead. (CVE-2014-0224)

   InnoDB Notes

     * Important Change: Redo log writes for large, externally stored
       BLOB fields could overwrite the most recent checkpoint. The
       5.6.20 patch limits the size of redo log BLOB writes to 10% of
       the redo log file size. The 5.7.5 patch addresses the bug
       without imposing a limitation. For MySQL 5.5, the bug remains
       a known limitation.
       As a result of the redo log BLOB write limit introduced for
       MySQL 5.6, innodb_log_file_size should be set to a value
       greater than 10 times the largest BLOB data size found in the
       rows of your tables plus the length of other variable length
       fields (VARCHAR, VARBINARY, and TEXT type fields). Failing to
       do so could result in "Row size too large" errors. No action
       is required if your innodb_log_file_size setting is already
       sufficiently large or your tables contain no BLOB data. (Bug
       #16963396, Bug #19030353, Bug #69477)

   Functionality Added or Changed

     * Replication: The new system variable binlog_impossible_mode
       controls what happens if the server cannot write to the binary
       log, for example, due to a file error. For backward
       compatibility, the default for binlog_impossible_mode is
       IGNORE_ERROR, meaning the server logs the error, halts
       logging, and continues updates to the database. Setting this
       variable to ABORT_SERVER makes the server halt logging and
       shut down the server if it can not write to the binary log.
       (Bug #51014, Bug #11758766)

     * CMake support was updated to handle CMake version 3. (Bug
       #19001781)

     * New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support
       that was introduced with 5.6.17 now comes with the
       platform-specific packaging source placed under the packaging
       directory, in the deb-precise, deb-wheezy, and deb-trusty
       directories. (Bug #19020385)

     * Support for LinuxThreads has been removed from the source
       code. LinuxThreads was superseded by NPTL in Linux 2.6. (Bug
       #17007529, Bug #72888, Bug #18913935)

     * By default, mysql_install_db creates a my.cnf file in the
       installation base directory using a template. This may be
       undesireable for some deployments. To enable this behavior to
       be suppressed, mysql_install_db now supports a --keep-my-cnf
       option to preserve any existing my.cnf file and not create a
       new my.cnf file. (Bug #71600, Bug #18205019)

     * The mysqlhotcopy utility is now deprecated and will be removed
       in a future version of MySQL. Among the reasons for this: It
       works only for the MyISAM and ARCHIVE storage engines; it
       works on Unix but not Windows. Alternatives include mysqldump
       and MySQL Enterprise Backup.

     * The timed_mutexes system variable has no effect and is
       deprecated.

   Bugs Fixed

     * Important Change; Replication: A DROP TABLE statement may be
       divided into multiple statements before it is sent to the
       binary log if it contains regular (not temporary) tables and
       temporary tables, or if it contains temporary tables using
       both transactional and non-transactional storage engines. Now,
       when using GTIDs, DROP TABLE statements affecting these
       combinations of tables are no longer allowed unless the value
       of the gtid_next system variable is AUTOMATIC. This is
       because, with GTIDs enabled on the server, issuing a DROP
       TABLE in the cases just described while having only one GTID
       associated with each statement (the SQL thread does this
       following SET gtid_next='uuid:number') causes problems when
       there are not enough GTIDs for assignment to all the resulting
       statements following the division of the original DROP TABLE.
       A DROP TABLE statement might be split due to the behavior of
       the statement with respect to the current transaction varying,
       depending on table characteristics, as follows:

          + DROP TABLE of a regular (not temporary) table is
            committed immediately

          + DROP TABLE of a temporary table using a transactional
            storage engine is committed with the current transaction
            (following COMMIT)

          + DROP TABLE of a temporary table that uses a
            nontransactional storage engine is committed immediately
       Naming all three of these types of tables in a single DROP
       TABLE statement causes the MySQL server to divide the original
       statement into three separate DROP TABLE statements in the
       binary log. If GTIDs are enabled but the value of gtid_next is
       not AUTOMATIC, issuing a DROP TABLE statement that mixes any
       of the table types described previously causes the server to
       have an insufficient number of GTIDs to write with all of the
       resulting statements into the binary log. In addition, DROP
       TABLE IF EXISTS is always written in the binary log for all
       tables specified in the statement, even if some or all of the
       tables do not exist.
       Because temporary tables are handled differently by DROP TABLE
       depending on whether they use a transactional or
       nontransactional storage engine, any tables named by a DROP
       TEMPORARY TABLE statement that do not exist are assumed to be
       transactional. This means that, if a DROP TEMPORARY TABLE with
       two nontransactional temporary tables is issued on the master,
       it would writes only one DROP TABLE statement naming both
       tables. If one of the temporary tables no longer exists on the
       slave, then, when the SQL thread executes the statement, it
       tries to divide it into multiple statements due to it
       affecting a nontransactional (but existing) temporary table
       and a nonexistent transactional temporary table; this leads to
       problems because the SQL thread has only one GTID for the
       original DROP TABLE statement but must write two DROP TABLE
       statements in the binary log.
       In addition, when the slave dropped temporary tables after
       detecting that the master had restarted, it logged one DROP
       TABLE statement per pseudo-thread and per database, but
       combined temporary tables using transactional and
       nontransactional storage engines in a single DROP TABLE
       statement.
       Now, we throw an error in the client session if gtid_next is
       set to a uuid:number value and a DROP TABLE statement is
       issued mixing any of the table types described previously.
       In addition, we now group the nonexistent temporary tables and
       assume them to be transactional only if at least one
       transactional temporary table is dropped by the statement. If
       no transactional temporary tables are dropped, any nonexistent
       temporary tables are assumed to be nontransactional temporary
       tables.
       The slave now also handles dropping of temporary tables
       correctly in the event of the restart by the master. (Bug
       #17620053)

     * InnoDB: Opening a parent table that has thousands of child
       tables could result in a long semaphore wait condition. (Bug
       #18806829)

     * InnoDB: For single item full-text searches, deleted documents
       were included in inverse document frequency (IDF)
       calculations. (Bug #18711306, Bug #72548)

     * InnoDB: On mysqld start, specifying multiple data files using
       the innodb_data_file_path option would return a Space id in
       fsp header error after data is written to the second file.
       (Bug #18767811)

     * InnoDB: A DELETE operation on a table with full-text search
       indexes raised an assertion. (Bug #18683832)
       References: See also Bug #14639605.

     * InnoDB: When calling the memcached flush_all command, InnoDB
       attempts to initialize a connection and a transaction. If the
       transaction is in TRX_STATE_NOT_STARTED state, InnoDB would
       fail to set CONN_DATA->CRSR_TRX to NULL, resulting in a
       serious error. (Bug #18652854)

     * InnoDB: When InnoDB is built as a shared library, attempting
       to load the InnoDB full-text search (FTS) INFORMATION_SCHEMA
       plugin would fail with a Can't open shared library
       'ha_innodb.so' error. (Bug #18655281, Bug #70178)

     * InnoDB: A regression introduced in MySQL 5.6.5 would cause
       full-text search index tables to be created in the system
       tablespace (space 0) even though innodb_file_per_table was
       enabled. (Bug #18635485)

     * InnoDB: The InnoDB memcached plugin would call plugin_del
       without acquiring the lock_plugin mutex. This bug fix also
       addresses a race condition in ib_cursor_delete_row. (Bug
       #18409840)

     * InnoDB: The fix for Bug#16418661 added superfluous
       buf_flush_list() logic to InnoDB startup code. (Bug #17798076,
       Bug #70899)

     * InnoDB: A race condition in fts_get_next_doc_id resulted in
       Duplicate FTS_DOC_ID and Cannot find index FTS_DOC_ID_INDEX in
       InnoDB index translation table errors. (Bug #17447086, Bug
       #70311)
       References: See also Bug #16469399.

     * InnoDB: Due to differences in memory ordering on different
       processor types, some mutex and read-write lock flags were not
       read consistently. (Bug #11755438, Bug #47213)

     * Partitioning: Selecting from a table having multiple columns
       in its primary key and partitioned by LIST COLUMNS(R), where R
       was the last (rightmost) column listed in the primary key
       definition, returned an incorrect result. (Bug #17909699, Bug
       #71095)

     * Replication: mysqlbinlog --raw did not check for errors caused
       by failed writes, which could result in silent corruption of
       binary logs. Now in such cases it stops with an error. (Bug
       #18742916, Bug #72597)

     * Replication: When a slave worker thread tried to execute a
       statement that was too large, the resulting error caused a
       crash. Now in such cases, the error is truncated to fit the
       size of the buffer. (Bug #18563480)

     * Replication: When using row-based replication, updating or
       deleting a row on the master that did not exist on the slave
       led to failure of the slave when it tried to process the
       change. This problem occurred with InnoDB tables lacking a
       primary key. (Bug #18432495, Bug #72085)

     * Replication: Quotation marks were not always handled correctly
       by LOAD DATA INFILE when written into the binary log. (Bug
       #18207212, Bug #71603)

     * Replication: Beginning in MySQL 5.6.20, when a user specified
       AUTO_INCREMENT value falls outside of the range between the
       current AUTO_INCREMENT value and the sum of the current and
       number of rows affected values it is replicated correctly. In
       previous versions, an error was generated by the slave even if
       the user specified AUTO_INCREMENT value fell outside of the
       range. (Bug #17588419, Bug #70583)

     * Replication: A group of threads involved in acquiring locks
       could deadlock when the following events occurred:

         1. Dump thread reconnects from slave; on master, a new dump
            thread tries to kill zombie dump threads; having acquired
            the thread's LOCK_thd_data, it is about to acquire
            LOCK_log.

         2. Application thread executing show binary logs, having
            acquired LOCK_log and about to acquire LOCK_index.

         3. Application thread executing PURGE BINARY LOGS; having
            acquired LOCK_index, it is about to acquire
            LOCK_thread_count.

         4. Application thread executing SHOW PROCESSLIST (or SELECT

            * FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired
            LOCK_thread_count and about to acquire the zombie dump
            thread's LOCK_thd_data.
       This leads to the 4 threads deadlocking in the same order
       which the threads have been listed here.
       This problem arises because there are ordering rules for
       LOCK_log and LOCK_index, as well as rules for ordering
       LOCK_thread_count and LOCK_thd_data, but there are no rules
       for ordering across these two sets of locks. This was because
       the internal mysqld_list_processes() function invoked by SHOW
       PROCESSLIST acquired LOCK_thread_count for the complete
       lifetime of the function as well as acquiring and releasing
       each thread's LOCK_thd_data. Now this function takes a copy of
       the threads from the global thread list and performs its
       traversal on these, and only after releasing
       LOCK_thread_count. During this traversal, removal from the
       global thread list is blocked using LOCK_thd_remove such that
       the copies that would otherwise be destroyed by the removal
       remain valid during traversal. The locking order following
       this fix is shown here:
LOCK_thd_remove -> LOCK_thd_data -> LOCK_log -> LOCK_index -> LOCK_th
read_count
       (Bug #17283409, Bug #69954)

     * Replication: On Windows, mysqldump failed if the error log
       file was deleted (missing) from the active MySQL server. (Bug
       #17076131)

     * Replication: Client applications should be able to set the
       BINLOG_DUMP_NON_BLOCK flag in the initial handshake packet
       (COM_BINLOG_DUMP). Clients connecting to a server issuing a
       COM_BINLOG_DUMP with the flag unset do not get an EOF when the
       server has sent the last event in the binary log, which causes
       the connection to block. This flag, which was removed in error
       in MySQL 5.6.5, is now restored in the current release.
       As part of this fix, a new --connection-server-id option is
       added to mysqlbinlog. This option can be used by the client to
       test a MySQL server for the presence of this issue. (Bug
       #71178, Bug #18000079)

     * When a SELECT included a derived table in a join in its FROM
       list and the SELECT list included COUNT(DISTINCT), the COUNT()
       returned 1 even if the underlying result set was empty. (Bug
       #18853696)
       References: This bug is a regression of Bug #11760197.

     * Enabling optimizer trace could cause a server exit for queries
       with a subquery in a HAVING clause. (Bug #18791851)

     * SHA and MD5 functions failed for operations using the internal
       filename character set and could cause a server exit. (Bug
       #18786138)

     * Large arguments passed to mysqldump could lead to buffer
       overflow and program exit. (Bug #18779944)

     * Compiler flags were not passed to DTrace, causing problems for
       32-bit builds cross-compiled on 64-bit platforms. (Bug
       #18593044)

     * ALTER TABLE on a partitioned table could result in the wrong
       storage engine being written into the table's .frm file and
       displayed in SHOW CREATE TABLE. (Bug #18618561)

     * With the max_heap_table_size system variable set to a large
       value (20GB), creation of a temporary table or a table using
       the MEMORY storage engine caused a server exit. (Bug
       #18463911)

     * For debug builds, a 0x00 character in a full-text query string
       that used the ujis_japanese_ci, utf8mb4_turkish_ci, or
       eucjpms_bin collation could raise an assertion. (Bug
       #18277305)

     * mysqladmin password masked the old password given on the
       command line, but not the new password. (Bug #18163964)

     * yaSSL code had an off-by-one error in certificate decoding
       that could cause buffer overflow.
       yaSSL code had an opendir() without a corresponding
       closedir(). (Bug #18178997, Bug #17201924)

     * For full-text queries on InnoDB tables, attempts to access
       deleted document IDs could lead to a server exit. (Bug
       #18079671)

     * MyISAM temporary files could be used to mount a code-execution
       attack. (Bug #18045646)

     * For queries that selected from the Performance Schema
       events_statements_current table, adding an ORDER BY clause
       could produce incorrect results. (Bug #17729044)

     * If a query had both MIN()/MAX() and
       aggregate_function(DISTINCT) (for example, SUM(DISTINCT)) and
       was executed using Loose Index Scan, the result values of
       MIN()/MAX() were set improperly. (Bug #17217128)

     * For UNION statements, the rows-examined value was calculated
       incorrectly. This was manifest as too-large values for the
       ROWS_EXAMINED column of Performance Schema statement tables
       (such as events_statements_current). (Bug #17059925)

     * Clients could determine based on connection error message
       content whether an account existed. (Bug #16513435, Bug
       #17357528)

     * An assertion could be raised when creating a index on a prefix
       of a TINYBLOB or GEOMETRY column in an InnoDB column. (Bug
       #16368875, Bug #18776592, Bug #17665767)

     * Use of a nonmultibyte algorithm for skipping leading spaces in
       multibyte strings could cause a server exit. (Bug #12368495,
       Bug #18315770)

     * For a view defined on a UNION, the server could create an
       invalid view definition. (Bug #65388, Bug #14117018, Bug
       #72018, Bug #18405221)

     * Configuring with cmake -DWITHOUT_SERVER to build clients
       without the server failed for builds outside of the source
       tree. (Bug #66000, Bug #14367046)

     * With big_tables enabled, queries that used COUNT(DISTINCT) on
       a simple join with a constant equality condition on a
       non-duplicate key returned incorrect results. (Bug #52582, Bug
       #11760197)
       References: See also Bug #18853696.

     * Deadlock could occur if three threads simultaneously performed
       INSTALL PLUGIN, SHOW VARIABLES, and mysql_change_user(). (Bug
       #71236, Bug #18008907, Bug #72870, Bug #18903155)

     * mysql_config_editor exited when given an empty argument to the
       --login-path option. (Bug #71837, Bug #18311024, Bug
       #18830493)

     * MySQL did not compile with Bison 3. A workaround is to
       downgrade to Bison 2. (Bug #71250, Bug #18017820, Bug
       #18978946)

     * Uninstalling and reinstalling semisynchronous replication
       plugins while semisynchronous replication was active caused
       replication failures. The plugins now check whether they can
       be uninstalled and produce an error if semisynchronous
       replication is active. To uninstall the master-side plugin,
       there must be no semisynchronous slaves. To uninstall the
       slave-side plugin, there must be no semisynchronous I/O
       threads running. (Bug #70391, Bug #17638477)

     * If there was a predicate on a column referenced by MIN() or
       MAX() and that predicate was not present in all the
       disjunctions on key parts earlier in the compound index, Loose
       Index Scan returned an incorrect result. (Bug #71097, Bug
       #17909656)

     * Client auto-reconnect did not work for clients linked against
       libmysqlclient, even with MYSQL_OPT_RECONNECT enabled. (Bug
       #70026, Bug #17309863)

     * Upgrades using RPM packages could change the ownership of an
       installation directory. (Bug #71715, Bug #18281535)

     * Proxy users were unable to execute statements if the proxied
       user password had expired. (Bug #71337, Bug #18057562)

     * A new CMake option, SUNPRO_CXX_LIBRARY, enables linking
       against libCstd instead of stlport4 on Solaris 10 or later.
       This works only for client code because the server depends on
       C++98. Example usage:
       cmake -DWITHOUT_SERVER=1 -DSUNPRO_CXX_LIBRARY=Cstd
       (Bug #72352, Bug #18605389)

     * File permissions and line endings of several test and
       configuration files were made more consistent to avoid
       warnings from package checkers. (Bug #68521, Bug #16415173,
       Bug #16395459, Bug #68517, Bug #16415032, Bug #71112, Bug
       #17919313, Bug #71113, Bug #17919422)

On Behalf of the MySQL/ORACLE RE Team,

Akhil Mohan