MySQL Community Server 5.7.8 has been released (part 2/3)

[Balasubramanian Kandasamy]

[This is part 2 of the announcement ]

     * InnoDB: A cascade operation resulted in a duplicate entry
       error in FTS_DOC_ID_INDEX. The same document ID was used
       by two cascade operations. (Bug #21111301, Bug #77087)

     * InnoDB: Starting the server with an invalid
       innodb_data_file_path setting did not produce a
       sufficiently informative error message. (Bug #21103446,
       Bug #77056)

     * InnoDB: A regression introduced in MySQL 5.7.5 caused
       sorting to be skipped when rebuilding a table after
       dropping a single-column primary key. (Bug #21103101)

     * InnoDB: Opening a foreign key-referenced table with
       foreign_key_checks enabled resulted in an error when the
       table or database name contained special characters. (Bug
       #21094069)

     * InnoDB: The page_zip_verify_checksum function returned
       false for a valid compressed page. (Bug #21086723)

     * InnoDB: DDL operations for tablespaces could fail to
       implicitly commit the current transaction. (Bug
       #21081898)

     * InnoDB: The rollback of a partially completed transaction
       containing more than one update to a spatial index raised
       an assertion in row_ins_sec_index_entry_by_modify(). (Bug
       #21076238)

     * InnoDB: In the case of a lock conflict, shutdown could
       hang waiting for asynchronous rollback to finish. (Bug
       #21075892)

     * InnoDB: To avoid conflicts with implicitly created
       file-per-table tablespaces, CREATE TABLESPACE ... ADD
       DATAFILE no longer supports creation of tablespace data
       files in subdirectories under the MySQL data directory
       (datadir). Additionally, the data file path specified in
       a CREATE TABLESPACE ... ADD DATAFILE statement must be an
       existing directory. InnoDB no longer creates missing
       directories for CREATE TABLESPACE ... ADD DATAFILE
       statements. (Bug #21068487)

     * InnoDB: SHOW ENGINE INNODB MUTEX functionality, which was
       removed in MySQL 5.7.2, was revised and added back. Mutex
       statistics collection can now be configured dynamically
       using the following options:

          + To enable the collection of mutex statistics, run:
            SET GLOBAL innodb_monitor_enable='latch';

          + To reset mutex statistics, run:
            SET GLOBAL innodb_monitor_reset='latch';

          + To disable the collection of mutex statistics, run:
            SET GLOBAL innodb_monitor_disable='latch';
       For more information, see SHOW ENGINE Syntax
       (http://dev.mysql.com/doc/refman/5.7/en/show-engine.html)

       Sync debug checking for the InnoDB storage engine,
       previously defined under UNIV_SYNC_DEBUG, is now defined
       under UNIV_DEBUG and is available when debugging support
       is compiled in using the WITH_DEBUG CMake option. When
       debugging support is compiled in, InnoDB sync debug
       checking is controlled by the innodb_sync_debug
       configuration option. (Bug #21052754)

     * InnoDB: A tablespace opened locally by a truncate routine
       was not closed in protected mode. (Bug #21046968)

     * InnoDB: An assertion was raised when truncation logic
       identified inactive undo tablespaces as candidates for
       undo log truncation. Some undo tablespaces were left
       inactive when the number of available undo tablespaces
       exceeded the number of undo logs. (Bug #21046781)

     * InnoDB: At startup, InnoDB updated the SYS_DATAFILES
       internal system table with the space_id and path of each
       system tablespace file even though a record was already
       present and SYS_DATAFILES.PATH matched the current value.
       (Bug #21044191)

     * InnoDB: In Windows debug builds, an innodb_flush_method
       setting of normal or unbuffered raised an assertion. (Bug
       #20981684)

     * InnoDB: Transactions could be subjected to rollback while
       performing DDL operations. The transactions were not
       marked as DDL transactions, and
       TRX_FORCE_ROLLBACK_DISABLE was not set. (Bug #20979020)

     * InnoDB: An ALTER TABLE ... IMPORT TABLESPACE operation on
       a table with prefix index failed with a schema mismatch
       error. (Bug #20977779, Bug #76877)

     * InnoDB: Initializing the database with an
       innodb_page_size setting of 64K and a system tablespace
       data file size less than 12MB raised an assertion. With
       an InnoDB page size of 64KB, the first system tablespace
       data file (ibdata1) was not large enough to contain the
       doublewrite buffer blocks (block1 and block2). To ensure
       that the doubwrite buffer blocks fit within the first
       system tablespace data file, a minimum data file size is
       now enforced. If innodb_page_size is less than or equal
       to 16KB, the minimum data file size for the first system
       tablespace data file (ibdata1) is 3MB. For
       innodb_page_size=32k, the minimum data file size is 6MB.
       For innodb_page_size=64k, the minimum data file size is
       12MB. (Bug #20972309)

     * InnoDB: Full-text search operations between tables
       related by a foreign key constraint were not properly
       cascaded during iterative DML cascading operations. (Bug
       #20953265)

     * InnoDB: In MySQL 5.7.2, 32 of 128 undo logs (rollback
       segments) were reserved as non-redo undo logs for
       temporary table transactions. With one of the remaining
       undo logs always allocated to the system tablespace, 95
       undo logs remained available for allocation to the system
       tablespace or separate undo tablespaces. This change
       effectively reduced the innodb_undo_tablespaces maximum
       limit from 126 to 95. In other words, a limit of 95
       available undo logs also limited the maximum number of
       undo tablespaces to 95. In MySQL 5.7.8, the
       innodb_undo_tablespaces maximum value is officially
       reduced to 95. (Bug #20938115)

     * InnoDB: A memory leak occurred when a foreign key
       constraint object was loaded with the parent table while
       the child table failed to load. The foreign key
       constraint object should only be loaded with the child
       table. (Bug #20926253, Bug #21041449)

     * InnoDB: Debug only code set m_prebuilt, which may affect
       in-place ALTER TABLE behaviour. m_prebuilt to should not
       be used to store an intermediate value in debug-only
       code. (Bug #20921940)

     * InnoDB: The definition of the fil_node_t data structure
       was moved from fil0fil.cc to fil0fil.h so that diagnostic
       code outside that module can access information about
       files that belong to a tablespace. (Bug #20886222)

     * InnoDB: Assertion code was revised to avoid compiler
       warnings that occurred when compiling MySQL on Mac OS X
       10.10.2. (Bug #20883256)

     * InnoDB: After upgrading to MySQL 5.7.6 or later,
       restarting the server after truncating a table that was
       originally created in MySQL 5.7.5 or earlier raised an
       "incorrect MERGE_THRESHOLD length in SYS_INDEXES" error.
       A MERGE_THRESHOLD column was added to the internal
       SYS_INDEXES table in MySQL 5.7.6. SYS_INDEXES records for
       tables that were not rebuilt or imported after upgrading
       did not include the new column. The TRUNCATE TABLE
       operation updated the table's SYS_INDEXES records to
       include the new column but set the MERGE_THRESHOLD value
       to NULL. (Bug #20882432)

     * InnoDB: A failure to load a change buffer bitmap page
       during a concurrent delete tablespace operation caused a
       server exit. (Bug #20878735)

     * InnoDB: A shutdown hang occurred when an
       innodb_force_recovery setting of 3 or higher prevented
       the rollback of transactions that were in an ACTIVE
       state. ACTIVE transactions are now placed in XA PREPARE
       state in the main-memory data structure to allow shutdown
       to proceed normally. The transactions are recovered as
       ACTIVE on the next restart and are rolled back unless
       innodb_force_recovery is again set to 3 or higher. (Bug
       #20874411)

     * InnoDB: If a server exit occurred during an XA ROLLBACK,
       the transaction was incorrectly recovered in XA PREPARE
       state. As a result, subsequent XA COMMIT transactions
       were possible, which would break ACID compliance and
       potentially cause corruption between indexes of a table.
       (Bug #20872655)

     * InnoDB: A CREATE TABLESPACE operation raised a Valgrind
       error due to a memory leak in the
       os_create_subdirs_if_needed function. (Bug #20865674)

     * InnoDB: Calls to buf_page_print() were removed to avoid
       filling mysql-test-run logs with InnoDB page dumps. Page
       dumps related to file I/O are still printed. (Bug
       #20863042)

     * InnoDB: CREATE TABLESPACE failed to move internal
       tablespace files to a reserved name space that starts
       with an innodb_ prefix, permitting internal tablespace
       files to be dropped. (Bug #20840368)

     * InnoDB: A TRUNCATE TABLE operation on a general
       tablespace table with a full-text search index raised an
       assertion. (Bug #20834483)

     * InnoDB: An assertion was raised on shutdown due to XA
       PREPARE transactions holding explicit locks. (Bug
       #20816223)

     * InnoDB: The fts_print_doc_id function printed too much
       debug information in debug builds. fts_enable_diag_print
       is now used instead. (Bug #20811125)

     * InnoDB: After a failed DROP TABLE operation, the purge
       background thread asserted while attempting to access an
       index page of the table. Purge should not attempt to
       clean a table that is marked as corrupt. Purge now checks
       for a corrupt primary index. (Bug #20789078, Bug #75913)

     * InnoDB: A checksum mismatch error on a crc32 checksum was
       encountered when restarting the server on a data file
       copied from a machine with a different endianness. The
       crc32 checksum should be recognized regardless of the
       native byte order of the system where the checksum was
       generated. (Bug #20783098, Bug #76375)

     * InnoDB: An ALTER TABLE ... DROP INDEX operation on a
       table with foreign key dependencies raised an assertion.
       (Bug #20768847)

     * InnoDB: An assertion was raised when InnoDB attempted to
       dereference a NULL foreign key object. (Bug #20762798)

     * InnoDB: An ALTER TABLE operation raised an assertion due
       a regression introduced in MySQL 5.7.6 with the
       introduction of native partitioning support for general
       tablespaces. (Bug #20759613)

     * InnoDB: In some instances, functions that call DBUG_ENTER
       did not call DBUG_RETURN. (Bug #20753620, Bug #76447)

     * InnoDB: A regression of the trx_is_started function in
       MySQL 5.7.6 caused a shutdown hang. (Bug #20744155)

     * InnoDB: The MeCab full-text plugin parser failed to
       handle an out-of-memory exception. (Bug #20742590)

     * InnoDB: An assertion was raised during a rollback
       operation due to a record the was incorrectly
       undelete-marked. (Bug #20734998)

     * InnoDB: An assertion was raised in a debug build when an
       ALTER TABLE operation invoked obsolete foreign key code
       while attempting to create an intrinsic temporary table
       as part of an optimizer plan. Temporary tables do not
       support foreign keys. Invocation of foreign key code is
       now blocked for intrinsic temporary tables. (Bug
       #20730289)

     * InnoDB: An INSERT operation raised an assertion. The
       calculation that determines the number of extents to
       reserve when storing a BLOB did account for compressed
       pages. (Bug #20713559)

     * InnoDB: Missing brackets in the fsp_flags_is_valid
       function could result in a failure to recognize a
       corrupted data file. (Bug #20671465)

     * InnoDB: A query that used a percentage character '%' as
       the last character in a query token raised a full-text
       parser plugin assertion. Full-text parser plugins created
       using the full-text parser plugin framework now ignore
       the '%' character if specified as the first or last
       character in a query token. Using the '%' character as
       the first character in a query token is not permitted by
       the internal SQL parser. Using the '%' character as last
       character in a query token is reserved for prefix
       matching. (Bug #20668156)

     * InnoDB: The INFORMATION_SCHEMA.FILES table now reports
       metadata for all InnoDB tablespace types including
       file-per-table tablespaces, general tablespaces, the
       system tablespace, temporary table tablespaces, and undo
       tablespaces (if present). System tablespace and temporary
       table tablespace metadata is no longer reported by the
       INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES and
       INFORMATION_SCHEMA.INNODB_SYS_DATAFILES tables. However,
       these tables continue to provide metadata for
       file-per-table and general tablespaces. (Bug #20660744,
       Bug #21086257, Bug #76182)

     * InnoDB: The InnoDB full-text search feature with the
       mecab parser plugin would print an empty error message.
       (Bug #20651493, Bug #76164)

     * InnoDB: Importing a tablespace with a full-text index
       resulted in an assertion when attempting to rebuild the
       index. (Bug #20637494)

     * InnoDB: A DML operation raised an assertion in
       btr_estimate_n_rows_in_range(). The assertion code was
       too strict. (Bug #20618309)

     * InnoDB: Defining a user-created FTS_DOC_ID column as a
       primary key produced incorrect full-text search relevancy
       rankings. (Bug #20597981)

     * InnoDB: During a table import operation, an INSERT failed
       with a duplicate key error on an AUTO_INCREMENT column
       due to an incorrectly initialized AUTO_INCREMENT value.
       (Bug #20597821, Bug #76037)

     * InnoDB: After dropping a full-text search index, the
       hidden FTS_DOC_ID and FTS_DOC_ID_INDEX columns prevented
       online DDL operations. (Bug #20590013, Bug #76012)

     * InnoDB: An assertion was raised on server startup when
       InnoDB tried to create a temporary file in a non-existent
       temporary directory (tmpdir) while in read-only mode.
       (Bug #20578834)

     * InnoDB: The strict_* forms of innodb_checksum_algorithm
       settings (strict_none, strict_innodb, and strict_crc32)
       caused the server to halt when a non-matching checksum
       was encountered, even though the non-matching checksum
       was valid. For example, with
       innodb_checksum_algorithm=strict_crc32, encountering a
       valid innodb checksum caused the server to halt. Instead
       of halting the server, a message is now printed to the
       error log and the page is accepted as valid if it matches
       an innodb, crc32 or none checksum. (Bug #20568464)

     * InnoDB: After moving the MySQL data directory and
       modifying the datadir configuration parameter to point to
       the new location, tables stored in general tablespaces
       failed to open because the tablespace data file could not
       be found. To address this problem, CREATE TABLESPACE ...
       ADD DATAFILE now creates an isl file in the MySQL data
       directory when a general tablespace data file is created
       outside of the MySQL data directory. Also, the
       fil_ibd_open function now searches for general
       tablespaces in the same way that it searches for
       file-per-table tablespaces. (Bug #20563954)

     * InnoDB: General tablespaces created on Windows using a
       relative data file path could not be opened on Unix-like
       systems. InnoDB failed to convert the backslash ("\")
       directory separator that is used in the Windows version
       of the relative data file path. (Bug #20555168)

     * InnoDB: General tablespaces now support partitioned
       InnoDB tables, and individual partitions and
       subpartitions can now be assigned to a general
       tablespace. SHOW CREATE TABLE output was revised to
       include quotes around the tablespace identifier. (Bug
       #20554858, Bug #20588947)

     * InnoDB: An ALTER TABLE operation that added a spatial
       index caused the server to exit. (Bug #20547644)

     * InnoDB: Assertion code which checks for the lowest
       possible page number for a tablespace did not account for
       general tablespaces. (Bug #20544581, Bug #20810627)

     * InnoDB: The InnoDB memcached plugin handled unsigned NOT
       NULL integer columns incorrectly. Thanks to Piotr
       Jurkiewicz for the patch. (Bug #20535517, Bug #75864)

     * InnoDB: The following changes were implemented for
       full-text index auxiliary tables:

          + If the primary table is assigned to a general
            tablespace, full-text auxiliary tables are created
            in the same general tablespace.

          + Full-text auxiliary tables are created with the same
            row format as the primary table.

          + If the primary table was created in a location
            outside of the data directory using the DATA
            DIRECTORY clause, full-text auxiliary tables are
            created in the same location as the primary table.
       (Bug #20527217, Bug #75869)

     * InnoDB: The memcached set command permitted a negative
       expire time value. Expire time is stored internally as an
       unsigned integer. A negative value would be converted to
       a large number and accepted. The maximum expire time
       value is now restricted to INT_MAX32 to prevent negative
       expire time values. (Bug #20478242, Bug #75790)

     * InnoDB: An interrupted ALTER TABLE operation that
       rendered a child table unavailable caused an error and
       debug assertion after crash recovery, when the ALTER
       TABLE operation on the parent table detected that the
       foreign keys of the parent table could not be loaded. The
       debug assertion was removed and the error was replaced by
       a warning. (Bug #20476395)
       References: This bug is a regression of Bug #19267051.

     * InnoDB: In debug builds, enabling the
       btr_cur_limit_optimistic_insert_debug flag raised a
       deadlock exception in the change buffer clustered index.
       (Bug #20459905, Bug #75736)

     * InnoDB: A warning message is now printed if DB_TRX_ID
       stored in a record is found to be greater than
       max_trx_id. In debug builds, an assertion is raised. (Bug
       #20445525)

     * InnoDB: Estimates for the number of records in a range
       for a given dataset could differ depending on the page
       size. (Bug #20427694)

     * InnoDB: During shutdown on Windows, the listener object
       in handle_shutdown() was freed while the listener was
       running, resulting in an exception in
       buf_pool_from_bpage(). (Bug #20421223)

     * InnoDB: SHOW ENGINE INNODB STATUS output showed negative
       reservation and signal count values due to a counter
       overflow error. (Bug #20417397)

     * InnoDB: Failure to check the status of a cursor
       transaction read-only option before reusing the cursor
       transaction for a write operation resulted in a server
       exit during a memcached workload. (Bug #20391552)

     * InnoDB: An assertion was raised in a debug build when
       populating a spatial index during an ALTER TABLE
       operation. The size of data tuples for compressed rows is
       calculated in the rec_get_converted_size_comp_prefix_low
       function. Debug code within the function did not account
       for the spatial index or the DATA_SYS_CHILD data type in
       the node pointers. (Bug #20372749)

     * InnoDB: CHECK TABLE returned a "wrong count" error for
       tables with spatial indexes. (Bug #20313067)

     * InnoDB: MDL locks taken by memcached clients caused a
       MySQL Enterprise Backup FLUSH TABLES WITH READ LOCK
       operation to hang. (Bug #20275612)

     * InnoDB: An embedded MySQL server failed to start with
       innodb_undo_tablespaces=2. The server was unable to
       locate undo tablespaces that were created when the MySQL
       instance was initialized. For embedded MySQL
       installations, the innodb_undo_directory default value of
       "." may not be the same directory as the MySQL data
       directory. To address this problem, innodb_undo_directory
       is now NULL by default, requiring that a path be
       specified. If a path is not specified, undo tablespaces
       are created in the MySQL data directory, as defined by
       datadir. A workaround for pre-MySQL 5.7.8 embedded
       installations is to define an absolute path for
       innodb_undo_directory. (Bug #20023425)

     * InnoDB: A DML operation raised an assertion in file
       lock0lock.cc. A session holding an exclusive row lock on
       a clustered index page initiated a page reorganization
       while another session waited for a lock on the same row.
       The page reorganization changed the lock order, causing
       an assertion in lock_rec_add_to_queue(). (Bug #20005279)

     * InnoDB: A DROP DATABASE operation raised an assertion.
       (Bug #19929435)

     * InnoDB: InnoDB failed to open a tablespace after the data
       directory location of the tablespace was changed from a
       relative path to a full path. InnoDB failed to recognize
       that the relative path, which remained embedded in the
       data dictionary, pointed to the same data file as the
       full path. (Bug #19896685)

     * InnoDB: A TRUNCATE TABLE operation appeared to hang when
       run in parallel with a read-write workload. (Bug
       #19873470, Bug #74312)

     * InnoDB: The sorted index build feature introduced in
       MySQL 5.7.5 caused a performance regression when adding
       an index to a small table. The regression was due to
       excessive flushing triggered by a forced checkpoint that
       occurs after the sorted index build. (Bug #19865673, Bug
       #74472)

     * InnoDB: Updates to indexed columns could be slower in
       MySQL 5.7.5 and higher. In pre-MySQL 5.7.5 releases,
       InnoDB reserves 1/16 of the space in clustered index
       pages for future inserts and updates. This behaviour
       changed in MySQL 5.7.5 with the introduction of the
       innodb_fill_factor option. With innodb_fill_factor=100,
       B-tree index pages were completely filled during sorted
       index builds, and subsequent updates to index pages
       resulted in page splitting. To restore pre-MySQL 5.7.5
       behavior, the default setting of innodb_fill_factor=100
       now leaves 1/16 of the space in clustered index pages
       free for future index growth. (Bug #19821087, Bug #74325)

     * InnoDB: The ha_innobase::index_flags function returned
       invalid flags for spatial indexes. (Bug #19473391)

     * InnoDB: On Windows, asynchronous I/O requests remained
       waiting after InnoDB initialization was aborted. (Bug
       #19363615)

     * InnoDB: An index record was not found on rollback due to
       inconsistencies in the purge_node_t structure. (Bug
       #19138298, Bug #70214, Bug #21126772, Bug #21065746)

     * InnoDB: The ut_when_dtor struct, added in MySQL 5.7 to
       address a Valgrind issue, was removed to reduce code
       complexity. (Bug #18309926)

     * InnoDB: An INSERT operation raised an assertion when the
       transaction mode was modified after the transaction
       started. (Bug #15866285)

     * InnoDB: Queries that use both UNION and UNION ALL and
       disable the index would cause an assertion due to
       duplicate B-tree values. (Bug #76439, Bug #20752543)

     * InnoDB: In debug builds, attempting to create a spatial
       index after dropping the mysql.innodb_table_stats table
       raised an assertion in the btr_cur_open_at_rnd_pos_func
       function. (Bug #76437, Bug #20753642)

     * InnoDB: Transaction objects were passed to intrinsic
       table APIs, causing an assertion. Intrinsic tables, which
       do not support rollback and are not shared across
       connections, should ignore the transaction objects. (Bug
       #76415, Bug #20748479)

     * InnoDB: When innodb_thread_concurrency=1, queries on
       intrinsic temporary tables caused other sessions to hang.
       Queries on intrinsic temporary tables should not
       increment the number of active threads. (Bug #76346, Bug
       #20762059)

     * Partitioning: During execution of correlated subqueries,
       the server reinitialized a scan executed on the same
       table without ending the previous scan. (Bug #20949314,
       Bug #76810)

     * Partitioning: CREATE TABLE statements that used an
       invalid function in a subpartitioning expression did not
       always fail gracefully as expected. (Bug #20310212)

     * Partitioning: For an ordered index scan over multiple
       partitions, MySQL performs a merge sort across them using
       a priority queue whose entries hold pointers to buffers
       containing fetched rows. When all rows from all
       partitions are fetched, this queue is now empty. When
       this occurred, subsequent attempts to fetch rows were
       done by passing a null buffer pointer, which caused the
       server to fail. This could manifest itself when executing
       HANDLER ... READ ... PREV against a partitioned table.
       Now in such cases this pointer holds NO_CURRENT_PART_ID
       so that the partitioning handler is aware that the queue
       is empty. (Bug #20270687)

     * Partitioning: REPAIR TABLE ... QUICK could fail when used
       with multiple partitioned tables. (Bug #76154, Bug
       #20647894)

     * Partitioning: In certain cases, ALTER TABLE ... REBUILD
       PARTITION was not handled correctly when executed on a
       locked table. (Bug #75677, Bug #20437706)

     * Replication: Some replication thread statuses were not
       being shown in the PROCESSLIST_INFO column of the threads
       table. (Bug #21127308)

     * Replication: When using multiple replication channels,
       issuing RESET SLAVE on a non-default replication channel
       removes the channel, whereas issuing RESET SLAVE on the
       default replication channel does not remove the channel,
       as it always exists. In previous versions, this meant
       that the default replication channel did not correctly
       reset some configuration and status parameters. The fix
       ensures that issuing RESET SLAVE on the default
       replication channel resets all parameters. (Bug
       #21107331, Bug #21111229)

     * Replication: SHOW BINLOG EVENTS was not showing the
       correct statement for XA COMMIT ... ONE PHASE. Although
       the event was logged and replicated correctly, SHOW
       BINLOG EVENTS was showing an incorrect statement when
       handling the event. The fix ensures that the statement is
       correctly displayed. (Bug #21053526)

     * Replication: In MySQL 5.7.7 and earlier, GTIDs were
       automatically disabled whenever --initialize or
       --bootstrap were enabled. In MySQL 5.7.8 and later GTIDs
       are not disabled when --initialize or --bootstrap are
       enabled. (Bug #20980271)

     * Replication: When using mysql-test-run.pl with the
       --ps-protocol option to run a test against a server with
       log_bin=OFF, setting gtid_next and then executing a DDL
       statement caused an error. This was due to the DDL
       statement not being correctly logged to consume the GTID
       specified when setting gtid_next. (Bug #20954452)

     * Replication: When log_bin=ON, if a read-only XA
       transaction was prepared but had an empty body, a
       subsequent XA ROLLBACK caused an assertion. (Bug
       #20902763)

     * Replication: explicit_defaults_for_timestamp has been
       changed from a global variable to a global and session
       variable, and the session variable is now replicated.
       This means that you can change the variable and still be
       guaranteed that every statement uses the same value for
       the variable on master and slave, even if the variable is
       not changed synchronously on master and slave. (Bug
       #20866059)

     * Replication: When changing gtid_mode online, if
       autocommit was set to 0 and a set gtid_next=UUID:NUMBER
       statement had been issued, then changing gtid_mode was
       not being blocked. The fix ensures that variables which
       can only be set outside transaction context can now only
       be set if the thread does not own a GTID and does not
       hold anonymous ownership. This changes the behavior of
       these variables:

          + enforce_gtid_consistency

          + gtid_mode

          + gtid_purged

          + session_track_gtids
       (Bug #20865683)

     * Replication: mysqlbinlog would apply any rewrite rules
       before applying the database filter. This meant that in
       cases when statement-based replication transactions were
       mixed with row-based replication transactions only one or
       the other type of transaction would be output. The fix
       changes the behavior so that the rewrite rules also apply
       to the USE db_name clause, rewriting the database
       specified by db_name according to the setting of the
       --rewrite-db parameter. This makes it possible to use the
       --database option on the query and row events. In
       addition, it removes the suppression of the USE db_name
       statement and ensures that the rewrite is done before the
       database filter. (Bug #20810442)

     * Replication: When slaves, and especially semisynchronous
       replication slaves, connected to a master there was a
       chance they could encounter a SLAVE HAS MORE GTIDS THAN
       THE MASTER HAS error. During connection the slave sends
       all replicated GTIDs to the master, and the master checks
       if all the GTIDs matching its server_uuid are included in
       its gtid_executed GTID set. There was a chance that a
       GTID was already in the slave's gtid_executed GTID set,
       but not in the master's gtid_executed GTID set. This was
       due to the GTID being added into gtid_executed after it
       was added to the binary log, meaning it was possible that
       a transaction had been replicated and applied on the
       slave, but not committed on the master yet. The fix
       ensures that the master checks if all GTIDs are in the
       union of gtid_executed and gtid_owned. (Bug #20464737)

     * Replication: A replication slave running with a gtid_mode
       other than OFF, log_bin=OFF and
       relay_log_info_repository=TABLE was consuming the GTID of
       a transaction prematurely when applying a transaction
       that spanned across distinct relay log files. This was
       caused when the slave SQL thread was flushing the relay
       log information to the mysql.slave_relay_log_info table
       while in the middle of a transaction, or immediately
       after the GTID of a transaction, because of the rotation
       of the relay log. The fix skips saving the gtid_state for
       operations that save the relay log information to the
       mysql.slave_relay_log_info table. (Bug #20451386)

     * Replication: When gtid_mode=ON, issuing a SET
       gtid_next='UUID:NUMBER' statement and then issuing a
       statement that caused an error, such as CREATE..SELECT,
       led to an assertion failure on COMMIT. This was due to
       gtid_next being incorrectly set to undefined for
       implicitly committing statements, even if the statement
       failed with an error before the implicit commit happened.
       (Bug #20343644, Bug #20444828)

     * Replication: If a slave was restarted with
       --relay-log-recovery enabled and the initialization of
       the default replication channel had failed, a slave could
       refuse to start or cause an assert in debug mode. (Bug
       #20191813, Bug #20236305)

     * Replication: When using RESET MASTER, the GTID state
       (gtid_executed and gtid_purged) is reset. On a server
       with log_bin=OFF, using RESET MASTER fails because the
       binary log is not enabled. However, since MySQL 5.7.5,
       GTIDs can be enabled even when the binary log is
       disabled. So in this case there was no way to reset the
       GTID state. The fix ensures that RESET MASTER can be
       executed on a server with GTIDs enabled and log_bin=OFF,
       enabling you to reset the GTID state. (Bug #19706455)

     * Replication: If statement based logging was in use, when
       updating multiple tables in a single statement, a single
       transaction could be logged as two different
       transactions. This was due to the binary logging process
       not properly identifying statements which were operating
       over transactional tables. The fix ensures that they are
       correctly identified, even if such statements do not
       change the contents of the tables. (Bug #16621582)

     * Replication: When starting more than one instance of
       mysqld on the same host at the same time, the instances
       could get the same server_uuid. The fix uses settings
       unique to each started mysqld instance to ensure that
       each gets a unique UUID. (Bug #16459136)

     * Replication: If flushing the cache to the binary log
       failed, for example due to a disk problem, the error was
       not detected by the binary log group commit logic. This
       could cause inconsistencies between the master and the
       slave. The fix uses the binlog_error_action variable to
       decide how to handle this situation. If
       binlog_error_action=ABORT_SERVER, then the server aborts
       after informing the client with an
       ER_BINLOGGING_IMPOSSIBLE error. If
       binlog_error_action=IGNORE_ERROR, then the error is
       ignored and binary logging is disabled until the server
       is restarted again. The same is mentioned in the error
       log file, and the transaction is committed inside the
       storage engine without being added to the binary log.
       (Bug #76795, Bug #20938915)

     * Replication: When a slave was stopped,
       replication_applier_status_by_worker showed worker_id as
       1 and did not show the correct number. (Bug #76637, Bug
       #20857660)

     * Replication: Setting SESSION.GTID_NEXT=default
       immediately after setting SESSION.GTID_NEXT='ANONYMOUS'
       causes an ER_CANT_SET_GTID_NEXT_WHEN_OWNING_GTID error,
       but this also changes the gtid_next type from ANONYMOUS
       to AUTOMATIC, meaning that the next transaction could
       potentially cause an GTID_NEXT->TYPE != AUTOMATIC_GROUP
       || THD->OWNED_GTID.IS_EMPTY() assertion. To avoid this
       possibility, the fix ensures that setting
       SESSION.GTID_NEXT=default does not change the gtid_next
       type if it could cause an error. (Bug #76434, Bug
       #20753378)

     * Replication: Additional replication channels could not be
       added if the server had been started with server_id=0,
       the default. The fix ensures that a replication slave
       checks the server_id is greater than 0 when CHANGE MASTER
       TO has been issued before continuing with the
       initialization of a channel. (Bug #76432, Bug #20753463,
       Bug #20712720)

     * Replication: When a server was configured with
       gtid_mode=ON, log-bin=OFF, and with autocommit enabled,
       during commit it was possible to encounter an ASSERTION
       `IS_STARTED()' FAILED error. This was possible when an
       applier thread committed a transaction's GTID into the
       gtid_executed table before transaction prepare when
       binary logging was disabled, or binary logging was
       enabled and log_slave_updates was disabled. The cause was
       that when the server was saving a transaction's GTID into
       the gtid_executed table, the calculated transaction
       context could be committed during the save phase when
       autocommit was enabled. The fix ensures that the
       transaction context is calculated after saving the GTID's
       state, and then commit is executed on any remaining
       transactions. (Bug #76425, Bug #20748570)

     * Replication: When using row-based logging with autocommit
       disabled and GTID_MODE=OFF_PERMISSIVE, if a transaction
       started with a CREATE TEMPORARY TABLE statement, then
       regardless of whether the table was transactional or
       non-transactional, the transaction began an automatic
       GTID violating transaction. However, if
       GTID_NEXT='UUID:NUMBER' was issued immediately after
       executing the CREATE TEMPORARY TABLE statement, which
       sets gtid_next type to GTID_GROUP, upon committing the
       transaction, a check for possible violation of GTID
       consistency was causing an assertion failure because the
       gtid_next type had been changed from AUTOMATIC_GROUP to
       GTID_GROUP.
       The fix ensures that transactions with an empty owned
       GTID correctly check if they break GTID consistency. As
       part of this fix, it was found that when autocommit was
       disabled, the statement CREATE TEMPORARY TABLE did not
       start a transaction, so immediately setting
       GTID_NEXT='UUID:NUMBER' could not cause an error. The fix
       ensures that when autocommit is disabled, executing
       CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE starts a
       transaction, regardless of the state of log_bin,
       binlog_format and whether a transactional or
       non-transactional storage engine is in use. This makes
       the behavior consistent, but is a change in logging when
       log-bin=OFF. (Bug #76416, Bug #20748502)

     * Replication: When using GTIDs with log-bin=OFF, a
       combination of statements which included a BINLOG
       statement executing a Format_description_log_event would
       cause an assertion. The reason was that the server would
       run the routine to handle the end of a GTID violating
       transaction, which was incorrect because when
       --log-bin=OFF the transaction should not have been
       handled as an offending transaction. The fix ensures that
       before the compatibility testing, the state of log_bin is
       checked. If log_bin=OFF, then the compatibility checks
       are skipped. This makes the server not activate flags
       that would then trigger the incorrect run of the routine
       to handle GTID violating transactions that ultimately
       resulted in an assertion. (Bug #76406, Bug #20743468)

     * Replication: When binary logging was enabled, using
       stored functions and triggers resulting in a long running
       procedure that inserted many records caused the memory
       use to increase rapidly. This was due to memory being
       allocated per variable. The fix ensures that in such a
       situation, memory is allocated once and the same memory
       is reused. (Bug #75879, Bug #20531812)

     * Replication: If an error occurred when using a
       multi-threaded slave, issuing a CHANGE MASTER TO
       statement which resulted in an
       ER_MTS_CHANGE_MASTER_CANT_RUN_WITH_GAPS error, and then
       issuing RESET SLAVE, made it impossible to change master
       due to repeated ER_MTS_CHANGE_MASTER_CANT_RUN_WITH_GAPS
       errors. Running the debug version of mysqld caused an
       unexpected exit in this case. The fix ensures that the
       recovery process for multi-threaded slaves avoids this.
       (Bug #75574, Bug #20411374)

     * Replication: When using semisynchronous replication
       performance was degrading when the number of threads
       increased beyond a certain threshold. To improve
       performance, now only the thread which is committing is
       responsible for deleting the active transaction node. All
       other operations do not touch this active transaction
       list. (Bug #75570, Bug #20574628)

     * Replication: When gtid_executed_compression_period is set
       to a number greater than 0, there is a thread that wakes
       up after every number of transactions specified by
       gtid_executed_compression_period to perform range
       compression on the mysql.gtid_executed table. There was a
       small chance that the thread would miss a signal and not
       wake up, so that one pass of the compression algorithm
       would be missed and the table left uncompressed. The fix
       ensures that the thread wakes up consistently. (Bug
       #75014, Bug #20104307)

     * Replication: Using mysqlbinlog to process log events
       greater than 1.6GB failed with an out of memory error.
       This was caused by an internal error converting the
       length variable. The fix upgrades the length variable to
       avoid overflow in both encoding and decoding functions.
       (Bug #74734, Bug #20350989)

     * Replication: Setting gtid_next inside a stored procedure
       and committing an empty transaction caused an error. This
       was due to the empty transaction not being correctly
       logged to consume the GTID specified by setting
       gtid_next. (Bug #74253, Bug #19774317)

     * Replication: Some messages that were meant to be printed
       when log_warnings was greater than 1 started appearing in
       the error log. The information regarding the
       multi-threaded applier in particular was too verbose and
       much of this information was very technical and
       development oriented. The fix ensures that these messages
       are not logged. (Bug #74203, Bug #19729278)

     * Replication: When using a multi-threaded slave with
       slave_preserve_commit_order=1, certain combinations of
       transactions being applied in parallel could cause a
       deadlock and stop the slave responding. The fix
       introduces a check for such deadlocks, so that when a
       transaction needs to wait for another transaction to
       release a row lock, InnoDB checks if there is a deadlock
       caused by the commit order. If it finds a deadlock caused
       by the commit order, it sets a deadlock flag for the
       slave worker which is holding the row lock. Then the
       worker rolls back its transaction and tries again. (Bug
       #74177, Bug #20136704)

     * Replication: When a master with --binlog_checksum=none
       and --gtid-mode=ON was replicating to a slave with
       --binlog_checksum=crc32, restarting the slave's SQL
       thread caused an Event crc check error. This was due to
       the Format_description_log_event from the master not
       being correctly found in existing relay logs after
       restarting the slave's SQL thread. The fix ensures that
       the Previous_gtids_log_event is correctly skipped and
       that the correct Format_description_log_event is found in
       existing relay logs after restarting the slave's SQL
       thread. (Bug #73806, Bug #20644100)

     * Replication: When gtid_mode=on, GTIDs are automatically
       added to the mysql.gtid_executed table. If a GTID was
       manually inserted into the mysql.gtid_executed table and
       then automatic update inserted the same GTID, the server
       crashed. Manually inserting GTIDs into
       mysql.gtid_executed is an unsupported operation, but this
       fix ensures that the server does not crash in such a
       situation. (Bug #73601, Bug #19451053)

     * Replication: When using GTIDs, a multi-threaded slave
       which had relay_log_recovery=1 and that stopped
       unexpectedly could encounter a relay-log-recovery cannot
       be executed when the slave was stopped with an error or
       killed in MTS mode error upon restart. The fix ensures
       that the relay log recovery process checks if GTIDs are
       in use or not. If GTIDs are in use, the multi-threaded
       slave recovery process uses the GTID protocol to fill any
       unprocessed transactions. (Bug #73397, Bug #19316063)

     * Replication: When master_info_repository=TABLE the
       receiver thread stores received event information in a
       table. The memory used in the process of updating the
       table was not being freed correctly and this could lead
       to an out of memory error. The fix ensures that after an
       event is flushed to the relay log file by a receiver
       thread, the memory used is freed. (Bug #72885, Bug
       #19390463, Bug #69848, Bug #20124342)

     * Replication: The status variables
       Rpl_semi_sync_master_net_wait_time and
       Rpl_semi_sync_master_net_avg_wait_time were always 0 in
       MySQL 5.7.4 and later. These variables are now deprecated
       and will be removed in a future version. (Bug #72627, Bug
       #18750614)

     * Replication: When two slaves with the same server_uuid
       were configured to replicate from a single master, the
       I/O thread of the slaves kept reconnecting and generating
       new relay log files without new content. In such a
       situation, the master now generates an error which is
       sent to the slave. By receiving this error from the
       master, the slave I/O thread does not try to reconnect,
       avoiding this problem. (Bug #72581, Bug #18731252)

     * Replication: If a slave encountered a
       ER_NET_READ_INTERRUPTED or ER_NET_WRITE_INTERRUPTED error
       while getting a timestamp or server ID from the master,
       setting MASTER_HEARTBEAT_PERIOD and so on, the slave's
       receiver thread stopped. The fix ensures that these
       errors are treated as transient network errors, and the
       slave receiver thread attempts to automatically reconnect
       to the master in such a situation. (Bug #71374, Bug
       #18091217)