MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Bjorn Munch Date:September 25 2014 8:54pm
Subject:MySQL Community Server 5.7.5 has been released (part 2/3)
View as plain text  
[Due to length restrictions, this announcement is split into three parts.
This is part 2.]

   Bugs Fixed

     * Performance; Replication: When processing the dump thread, a
       semisynchronous replication master checked whether or not the
       dump thread came from a semisynchronous slave by checking the
       value of rpl_semi_sync_slave_enabled, but did so for every
       operation performed on this thread, which had significant
       negative impact on performance. Now this check is made only
       once, when the dump thread is started, which should noticeably
       improve the performance of semisynchronous replication in most
       cases. (Bug #17932935)

     * Important Change; Partitioning: In an ALTER TABLE statement,
       the server accepted REBUILD with the name of a subpartition as
       valid syntax even though the REBUILD keyword in this case did
       nothing. Now REBUILD is rejected in such cases, and causes the
       statement to fail with an error. (Bug #19075411, Bug #73130)
       References: This bug is a regression of Bug #14028340, Bug
       #65184.

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

     * Important Change; Replication: The maximum length that can be
       used for the password in a CHANGE MASTER TO statement is 32
       characters. Previously, when a longer password was employed,
       it was accepted, but any excess length was silently truncated
       by the server. Following this fix, when the password's length
       exceeds 32 characters, CHANGE MASTER TO fails with an error.
       (Bug #11752299, Bug #43439)

     * InnoDB; Partitioning: Large numbers of partitioned InnoDB
       tables could consume much more memory when used in MySQL 5.6
       or 5.7 than the memory used by the same tables used in
       previous releases of the MySQL Server. (Bug #17780517, Bug
       #70641)
       References: This bug was introduced by Bug #11764622, Bug
       #57480.

     * InnoDB: If a crash occurs after a drop index action during a
       TRUNCATE TABLE operation, the root page could be left in a
       free state. On crash recovery, an LSN
       (http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_lsn
       ) check failed to check free pages when attempting to pin the
       root page, resulting in an assertion. (Bug #19520482)

     * InnoDB: The TTASFutexMutex, the mutex implementation that uses
       the Linux futex, failed to request m_lock_word alignment. (Bug
       #19525395, Bug #73760)

     * InnoDB: Removed unused code related to binlog information
       stored in the InnoDB trx_sys page. (Bug #19471743)

     * InnoDB: Replaced a goto statement with an if statement in the
       fil_mutex_enter_and_prepare_for_io function in fil0fil.cc.
       (Bug #19488149)

     * InnoDB: An ALTER TABLE ... ADD FOREIGN KEY operation could
       cause a serious error. (Bug #19471516, Bug #73650)

     * InnoDB: An INSERT operation on a table with spatial data
       columns raised an assertion. (Bug #19474851)

     * InnoDB: A transaction returned from the transaction pool was
       not in a clean state. (Bug #19244969)

     * InnoDB: An ALTER TABLE operation raised an fk_tables.empty()
       assertion. After calling dict_load_foreigns(), all associated
       tables that are linked by a foreign key should be loaded to
       ensure that foreign keys are cached. (Bug #19267051)
       References: This bug is a regression of Bug #16244691.

     * InnoDB: In debug builds, an INSERT operation affecting
       compressed tables would raise a sync-related assertion. (Bug
       #19295893)

     * InnoDB: Reduced mem_heap_zalloc calls in upd_create. Only a
       single call is necessary to allocate memory for upd_t. (Bug
       #19297656, Bug #73272)

     * InnoDB: Retrieval of multiple values with a single get command
       would return incorrect results instead of an error message.
       The InnoDB memcached plugin does not currently support
       retrieval of multiple values with a single get command. (Bug
       #19172212, Bug #72453)

     * InnoDB: When multiple daemon_memcached_option options are
       defined, the INFORMATION_SCHEMA.GLOBAL_VARIABLES table and
       SHOW VARIABLES statement should only display the first
       daemon_memcached_option option that is defined in the command
       line string or in the MySQL configuration file. (Bug
       #19204759, Bug #73287)

     * InnoDB: Removed unused one_flush variable from
       storage/innobase/include/log0log.h. (Bug #19192364, Bug
       #73269)

     * InnoDB: Running SHOW ENGINE INNODB STATUS repeatedly under
       performance testing conditions could result in a serious
       error. (Bug #19196052)

     * InnoDB: Attempting to perform operations on a timed out key
       would cause the memcached daemon to crash and restart. (Bug
       #19172013, Bug #72586)

     * InnoDB: An MLOG_CHECKPOINT marker was incorrectly omitted when
       performing a log checkpoint. (Bug #19233510)

     * InnoDB: On crash recovery, InnoDB would call exit() when
       encountering a corruption or inconsistency. Some of the exit()
       calls have been removed to allow InnoDB to shut down properly.
       (Bug #19229231)

     * InnoDB: With a transaction isolation level less than or equal
       to READ COMMITTED, gap locks were not taken when scanning a
       unique secondary index to check for duplicates. As a result,
       duplicate check logic failed allowing duplicate key values in
       the unique secondary index. (Bug #19140907)
       References: This bug is a regression of Bug #16133801.

     * InnoDB: Improved error handling, diagnostics, and test
       coverage related to crash recovery error handling. (Bug
       #19145637, Bug #73179)

     * InnoDB: Improved error handling for calls to
       handler::records(). (Bug #19142753)
       References: This bug is a regression of Bug #16802288.

     * InnoDB: An ALTER TABLE operation that does not perform a sort
       on the clustered index could result in a duplicate record.
       (Bug #19163915)
       References: See also Bug #17657223.

     * InnoDB: The INNODB_PAGE_ATOMIC_REF_COUNT CMake option is
       removed in MySQL 5.7.5. This option was enabled by default but
       could be disabled for systems that do not support atomics. As
       of MySQL 5.7.5, support for atomics is required to build
       MySQL, making the INNODB_PAGE_ATOMIC_REF_COUNT option
       obsolete. (Bug #19061440)

     * InnoDB: A race condition that occurred when dynamically
       disabling innodb_adaptive_hash_index caused the purge thread
       to assert. (Bug #19069698)

     * InnoDB: In debug builds, an invalid rw_latch == RW_NO_LATCH
       assertion would cause the server to halt. (Bug #18977128)

     * InnoDB: A code comment for the os_event_is_set function in
       storage/innobase/os/os0event.cc was incorrect. (Bug #18940008,
       Bug #72919)

     * InnoDB: Added debug assertions to the adaptive hash index code
       to check that the tablespace ID in buffer blocks match the
       index space. (Bug #18965518, Bug #72986)

     * InnoDB: During recovery, a segmentation fault would occur when
       marking a table as corrupt. (Bug #18942294)

     * InnoDB: A latching order violation would occur while inserting
       BLOB data. (Bug #18883885)

     * InnoDB: trx_cleanup_at_db_startup failed to reset
       trx->rsegs->m-redo content in debug code. (Bug #18795594)

     * InnoDB: Removed unused function definitions and declarations
       from the InnoDB memcached API. (Bug #18815992, Bug #72723)

     * InnoDB: The innodb_memcached_config.sql configuration script
       failed after running the mysql_secure_installation script,
       which removes the MySQL test database. The
       innodb_memcached_config.sql script now creates the test
       database if it does not exist. (Bug #18816381, Bug #72678)

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

     * InnoDB: A regression introduced by the fix for Bug #11758237
       resulted in a cursor->index->name == TEMP_INDEX_PREFIX
       assertion. (Bug #18723872)

     * 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: When storing BLOB data, InnoDB failed to reserve the
       required tablespace pages prior to allocating the pages, which
       raised an assertion on INSERT. (Bug #18756233)

     * InnoDB: A failed in-place ALTER TABLE operation would leave
       behind non-unique temporary file names in the data dictionary
       preventing future ALTER TABLE operations on the same table due
       to temporary file name conflicts. To avoid this problem,
       temporary file names are made unique by appending a static
       global number that is initialized to a random distributed
       32-bit number using ut_time() and ut_crc32(). The number is
       then incremented atomically for each assigned temporary file
       name. Previously, temporary files were named using the format
       #sql-ibtid, where tid is the table ID. Temporary files are now
       named using the format #sql-ibtid-inc, where tid is the table
       ID and inc is the incremented number. (Bug #18734396, Bug
       #72594)

     * InnoDB: The page_create function has been optimized to use
       simpler functions to initialize pages. (Bug #18704384)

     * InnoDB: An INSERT operation on a table with BLOB columns
       raised an assertion. (Bug #18646430)
       References: This bug is a regression of Bug #16963396.

     * 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 failed
       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: To-be-imported tablespace files (FIL_TYPE_IMPORT) were
       not flushed after being converted to normal tablespace files
       (FIL_TYPE_TABLESPACE), resulting in too many open files. (Bug
       #18663997)
       References: This bug is a regression of Bug #18236692.

     * InnoDB: On startup, with innodb_file_per_table=ON, the page
       cleaner thread would raise a srv_get_active_thread_type() ==
       SRV_NONE debug assertion when encountering an active master
       thread. (Bug #18598813)

     * InnoDB: After upgrading from 5.6.10 to MySQL versions up to
       and including MySQL 5.6.18, InnoDB would attempt to rename
       obsolete full-text search auxiliary tables on server startup,
       resulting in an assertion failure. (Bug #18634201, Bug #72079)

     * InnoDB: After running OPTIMIZE TABLE on an InnoDB table with a
       spatial index, running a SELECT statement that uses the
       spatial index could result in a crash. (Bug #18619945, Bug
       #72361)
       References: This bug is a regression of Bug #13975225.

     * InnoDB: An INSERT operation on a table with GEOMETRY columns
       raised an assertion in rtr_page_split_and_insert(). (Bug
       #18644435)

     * InnoDB: The temporary tablespace file (ibtmp1) was held open
       by the page_cleaner thread and could not be removed on
       startup, resulting in a hang. (Bug #18642372)

     * InnoDB: InnoDB would try to merge a b-tree change buffer for a
       dedicated undo tablespace. (Bug #18593561)

     * 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: In rare cases, the purge process would attempt to
       delete a secondary index record that was not marked for
       deletion, resulting in an inconsistent secondary index. (Bug
       #18631496)

     * InnoDB: Included unistd.h in innodb.cmake to enable futexes in
       debug builds. (Bug #18522549, Bug #72225)

     * InnoDB: A DB_LOCK_WAIT during a foreign key check caused
       redundant delete marking, resulting in a failing assertion.
       (Bug #18451287)

     * InnoDB: TRUNCATE TABLE would write page-level redo logs during
       the DROP TABLE step of a TRUNCATE TABLE operation. (Bug
       #18511398)

     * InnoDB: srv_active_wake_master_thread() was called directly in
       innobase_commit and innobase_prepare, waking up the master
       thread and incrementing srv_activity_count.
       srv_active_wake_master_thread() should only be called after
       committing write transactions, not after read-only
       transactions or rollbacks. This patch also replaces some calls
       to srv_active_wake_master_thread() with calls to
       ib_wake_master_thread(). (Bug #18477009, Bug #72137)

     * InnoDB: A COMMIT operation related to full-text search
       resulted in a segmentation fault. (Bug #18503734)

     * InnoDB: The os_event_wait_time_low function would sometimes
       return OS_SYNC_TIME_EXCEEDED before the sync time has elapsed.
       (Bug #18386498)

     * InnoDB: Running a SELECT on a partitioned table caused a
       memory access violation in memcpy(). (Bug #18383840)
       References: See also Bug #18167648.

     * InnoDB: With UNIV_SYNC_DEBUG enabled, a late call to
       sync_check_enable() would result in an m_enabled assertion
       failure. (Bug #18433658)

     * InnoDB: InnoDB would write to the redo log for an IMPORT
       TABLESPACE operation before the tablespace import was
       complete. (Bug #18424134)

     * 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: With persistent statistics enabled, SHOW TABLE STATUS
       output and the TABLE_ROWS column of INFORMATION_SCHEMA.TABLES
       could report an incorrect number of table rows for tables with
       externally stored pages. (Bug #18384390)

     * InnoDB: Added the C++ ostream mechanism for error logging.
       (Bug #18320915)

     * InnoDB: Code quality improvements for the redo log subsystem.
       (Bug #18345004)

     * InnoDB: The fix for Bug#17699331 caused a high rate of
       read/write lock creation and destruction which resulted in a
       performance regression. (Bug #18345645, Bug #71708)

     * InnoDB: A regression introduced by the fix for Bug#18069105
       could result in a table corruption and failing assertions.
       (Bug #18368345)

     * InnoDB: The data file was not opened prior to calling
       fil_fusionio_enable_atomic_write(), resulting in an assertion
       failure. (Bug #18368241)

     * InnoDB: Removed the recv_max_parsed_page_no code variable,
       which was only used in a diagnostic error message. (Bug
       #18312967)

     * InnoDB: buf_pool->flush_rbt, which is only intended to be used
       for recovery, would be allocated for database creation and
       never freed. (Bug #18253089)

     * InnoDB: Calls to sched_getcpu would cause page faults. (Bug
       #18225489)

     * InnoDB: ib_heap_resize failed to verify that new_size is
       greater than or equal to old_size before calling memcpy. (Bug
       #18178915)

     * InnoDB: After crash recovery and with UNIV_DEBUG enabled,
       purge failed with a buf_pool_from_bpage(bpage) == buf_pool
       assertion failure. (Bug #18154145)

     * InnoDB: For each insert, memset would be called three times to
       allocate memory for system fields. To reduce CPU usage, the
       three memset calls are now combined into a single call. (Bug
       #17858679, Bug #71014)

     * InnoDB: Assertion code in buf_page_release_latch() in
       buf0buf.ic was too restrictive. (Bug #17869571)

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

     * InnoDB: A problem renaming temporary tables during an ALTER
       TABLE operation would raise an assertion and print a warning
       to the error log. Temporary table names were not sufficiently
       unique. (Bug #17713871)

     * InnoDB: In-place ALTER TABLE operations requiring a table
       rebuild would sort the clustered index even though the primary
       key order remained unchanged. This behavior caused unnecessary
       temporary table usage and I/O. (Bug #17657223)

     * 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: Enabling the InnoDB Table Monitor would result in a
       ib_table->stat_initialized assertion failure. (Bug #17039528,
       Bug #69641)

     * InnoDB: 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. (Bug #16963396, Bug #19030353, Bug #69477)

     * InnoDB: The error log message that is printed on CREATE TABLE
       when the number of BLOB or TEXT fields exceed the row size
       limit did not provide sufficient information. The error
       message now provides the maximum row size, current row size,
       and the field that causes the maximum row size to be exceeded.
       (Bug #16874873, Bug #69336)

     * InnoDB: An in-place ALTER TABLE operation on a table with a
       broken foreign key constraint could raise an assertion. (Bug
       #16869435)

     * InnoDB: The lock_number_of_rows_locked function used a bit
       vector to track the number of record locks held by a
       transaction. To optimize reporting, the bit vector was
       replaced by a simple counter. (Bug #16479309, Bug #68647)

     * InnoDB: Inserting a record into an InnoDB table with a key
       that falls between the maximum key of a full page and the
       minimum key of the "next" page could result in unnecessary
       page splits and under-filled pages. If the insert point is at
       the end of a page, InnoDB now attempts to insert to the next
       page before splitting the page. (Bug #15923864, Bug #67718)

     * InnoDB: With innodb_max_dirty_pages_pct=0 buffer pool flushing
       would not be initiated until the percentage of dirty pages
       reached at least 1%, which would leave up to 1% of dirty pages
       unflushed. (Bug #13029450, Bug #62534)

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

     * InnoDB: When foreign_key_checks is disabled, InnoDB would
       allow an index required by a foreign key constraint to be
       dropped, thereby placing the table into an inconsistent state.
       Dropping an index required by a foreign key constraint should
       not be permitted. (Bug #70260, Bug #17449901)

     * InnoDB: Debug assertion code in file row0ins.cc did not
       account for rw-lock shared-exclusive (sx-lock) mode, resulting
       in an assertion failure. (Bug #73534, Bug #19420253)

     * Partitioning: When the index_merge_intersection flag (enabled
       by default) or the index_merge_union flag was enabled by the
       setting of the optimizer_switch system variable, queries
       returned incorrect results when executed against partitoned
       tables that used the MyISAM storage engine, as well as
       partitioned InnoDB tables that lacked a primary key. (Bug
       #18167648)
       References: See also Bug #16862316, Bug #17588348, Bug
       #17648468.

     * 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: Misleading or confusing error messages have been
       revised, which were produced in the following 2 cases when
       using mysqlbinlog with the --raw option:

          + When this option was used together with --include-gtids.

          + When this option was used together with --exclude-gtids
            and --read-from-remote-master=BINLOG-DUMP-NON-GTIDS.
       (Bug #19459836, Bug #73625)

     * Replication: After the fix for Bug #16861624, killing a
       multi-threaded slave worker which was waiting for a commit
       lock caused a debug assertion to fail. This fix ensures that
       such a situation can not occur. (Bug #19311260)

     * Replication: Temporary errors related to a slave worker thread
       which was retrying a transaction were visible in SHOW SLAVE
       STATUS. This fix ensures that slave worker threads do not
       store temporary errors in the slave status. (Bug #19282301)

     * Replication: Removed an unnecessary write lock that was taken
       by an internal function while adding a GTID to a GTID set,
       which should improve the performance of the function and the
       code dependent on it during such operations. (Bug #18963555,
       Bug #72977)

     * Replication: RESET SLAVE ALL did not clear IGNORE_SERVER_IDS,
       although this statement should clear any values that are set
       by CHANGE MASTER TO. Now RESET SLAVE ALL always empties the
       list of server IDs to ignore, whenever it is executed. (Bug
       #18816897)

     * Replication: The same internal function had effects which
       caused three similar problems when resetting or starting
       slaves. These three issues are listed here:

          + RESET SLAVE automatically set the heartbeat period
            (Slave_heartbeat_period) to its default value.

          + RESET SLAVE automatically set SSL_VERIFY_SERVER_CERT to
            the default.

          + When a server was not configured as a slave (that is,
            when no CHANGE MASTER TO statement had yet been
            executed), the subsequent failure of START SLAVE was
            expected but had the unintended side effect of resetting
            the heartbeat period to the default.
       The function has been rewritten such that code affecting
       heartbeat or SSL certificate usage has been eliminated or
       moved to a more appropriate location, eleminating the side
       effects formerly seen with RESET SLAVE or a failed START
       SLAVE.
       As part of this fix, in order to be able to keep heartbeats
       enabled by default when changing the master, if host and port
       are given but the heartbeat period is not specified in a
       CHANGE MASTER TO statement, we force it to the default value.
       (Bug #18791604, Bug #18778485, Bug #18777899)

     * Replication: Semi-synchronous replication did not work as
       expected when the rpl_semi_sync_master_wait_no_slave and
       rpl_semi_sync_master_wait_for_slave_count variables were set.
       The values of the variables were changed, but the related
       internal status was not updated during initialization. (Bug
       #18835117, Bug #18466390)

     * 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 committing a transaction, a flag is now used
       to check whether a thread has been created, rather than
       checking the thread itself, which uses more resources,
       particularly when running the server with
       master_info_repository=TABLE. (Bug #18684222)
       References: See also Bug #17967378.

     * 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 GTIDs with MASTER_AUTO_POSITION
       enabled, if an I/O thread was restarted it failed with an
       ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error due to a partial
       transaction not being correctly rolled back before resuming
       the I/O thread. This fix ensures that the partial transaction
       is correctly rolled back. (Bug #18472603)

     * Replication: Log rotation events could cause
       group_relay_log_pos to be moved forward incorrectly within a
       group. This meant that, when the transaction was retried, or
       if the SQL thread was stopped in the middle of a transaction
       following one or more log rotations (such that the transaction
       or group spanned multiple relay log files), part or all of the
       group was silently skipped.
       This issue has been addressed by correcting a problem in the
       logic used to avoid touching the coordinates of the SQL thread
       when updating the log position as part of a relay log rotation
       whereby it was possible to update the SQL thread's coordinates
       when not using a multi-threaded slave, even in the middle of a
       group. (Bug #18482854)

     * 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: A multi-threaded slave now checks that a free
       worker is available to dispatch the next event. In previous
       versions, a multi-threaded slave crashes with a worker error
       if the thread coordinator can not find a free worker. The
       crash was caused when the coordinator did not return a free
       worker, for example if the coordinator was aborted at the same
       time using STOP SLAVE. (Bug #18363515)

     * Replication: When replicating from a MySQL 5.5 or earlier
       master to a MySQL 5.6 or later slave, the SOURCE_UUID column
       of the slave's
       performance_schema.replication_connection_status table
       contained random data. Now in such cases, SOURCE_UUID is left
       blank. (Bug #18338203)

     * Replication: During relay log initialization, the thread
       context was used as a flag for the reconstruction of the
       retrieved GTID set, an operation that does not depend on this
       parameter. This could be problematic if relay log
       initialization was called in another context other than the
       legacy replication scenario; if the invocation was made in a
       context where the thread context was always present, this
       prevented the set's reconstruction. The opposite could also
       happen when the thread context was not present, which cause
       the initialization to be performed twice.
       To avoid such issues, the thread context flag is replaced with
       a new flag that allows the reconstruction in all contexts but
       prevents multiple invocations. (Bug #18337036)

     * Replication: When mysqlbinlog processed multiple binary log
       files into a single output file, this file was not in a useful
       state for point-in-time recovery, when it failed with the
       error, When @@SESSION.GTID_NEXT is set to a GTID, you must
       explicitly set it to a different value after a COMMIT or
       ROLLBACK. Please check GTID_NEXT variable manual page for
       detailed explanation. Current @@SESSION.GTID_NEXT is 'xyz'.
       When mysqlbinlog processes a binary log containing GTIDs, it
       outputs SET gtid_next statements, but gtid_next is set to
       undefined whenever a commit occurs; this left gtid_next
       undefined when the server had finished processing the output
       from mysqlbinlog. When the next binary log file started with
       one or more anonymous statements or transactions, the
       combination of gtid_next being left undefined at the end of
       the first binary log and the second binary log containing
       anonymous transactions to the error described previously
       (Error 1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
       To fix this issue, now, whenever mysqlbinlog encounters this
       situation, it inserts SET gtid_next = AUTOMATIC if required to
       avoid leaving the previous binary log with gtid_next
       undefined.
       In addition, as a result of this fix, mysqlbinlog no longer
       outputs session variable information for every binary log;
       now, this value is printed only once unless it changes. (Bug
       #18258933, Bug #71695)

     * Replication: Changing master_info_repository between TABLE and
       FILE could produce duplicate values in the
       Replicate_Ignore_Server_Ids column of the output from SHOW
       SLAVE STATUS and the Ignored_server_ids column of the
       mysql.slave_master_info table. This could arise because the
       list of IDs stored internally by the server was not always
       sorted before checking for duplicates when inserting new
       values into the list. Now the list of server IDs to be ignored
       is always sorted, prior to performing this check. (Bug
       #18192817, Bug #18593479, Bug #18920203)

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

     * Replication: In certain cases, the server mishandled triggers
       and stored procedures that tried to modify other tables when
       called by CREATE TABLE ... SELECT. This is now handled
       correctly as an error. (Bug #18137535)

     * Replication: The REPLICATE_WILD_DO_TABLE and
       REPLICATE_WILD_IGNORE_TABLE options for CHANGE REPLICATION
       FILTER could be employed with values which contained no period
       (.) character, even though values for these options must be in
       the format db_name.tbl_name.. (Bug #18095449)

     * Replication: When used on a table employing a transactional
       storage engine, a failed TRUNCATE TABLE was still written to
       the binary log and thus replayed on the slave. This could lead
       to inconsistency when the master retained data that was
       removed on the slave.
       Now in such cases TRUNCATE TABLE is logged only when it
       executes successfully. (Bug #17942050, Bug #71070)

     * 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: When the I/O thread reconnected to a master using
       GTIDs and multithreaded slaves while in the middle of a
       transaction, it failed to abort the transaction, leaving a
       partial transaction in the relay log, and then retrieving the
       same transaction again. This occurred when performing a
       rotation of the relay log. Now when reconnecting, the server
       checks before rotating the log in such cases, and waits first
       for any ongoing transaction to complete. (Bug #17326020)

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

     * Replication: When the binary log was rotated due to receipt of
       a SIGHUP signal, the new binary log did not contain the
       Previous_gtid_event required for subsequent processing of that
       binary log's GTID events. Now when SIGHUP is received, steps
       are taken to insure that the server writes the necessary
       Previous_gtid_event to the new log before writing any GTID
       events to the new log. (Bug #17026898)

     * Replication: When using semisynchronous replication, if the
       binary log position was changed to a future position on a
       slave then an assertion error was generated on the master.
       This fix ensures that in such a situation the future position
       is correctly acknowledged and an error is instead generated on
       the slave. (Bug #70327, Bug #17453826)

     * Replication: When an SQL thread which was waiting for a commit
       lock was killed and restarted it caused a transaction to be
       skipped on slave. This fix ensures that thread positions are
       correctly persisted and transactions resume at the correct
       position. (Bug #69873, Bug #17450876)

     * Replication: On a master that is using semisynchronous
       replication, where rpl_semi_sync_master_wait_no_slave is
       enabled and rpl_semi_sync_master_timeout is set to long
       timeout, killing the I/O thread could cause the server to hang
       on shutdown. This fix ensures that if the dump thread finds
       that there no semisynchronous slaves connected to the master,
       the setting of rpl_semi_sync_master_wait_no_slave is ignored
       and the shutdown proceeds correctly. (Bug #71047, Bug
       #17879675)

     * Replication: When using row-based replication, setting a
       slave's slave_rows_search_algorithms variable to HASH_SCAN
       caused an ER_RECORD_NOT_FOUND error even though that record
       existed in the storage layer. This fix ensures that the unique
       key for each record is correctly maintained and such a
       situation does not occur. (Bug #72788, Bug #18860225)

     * Replication: When an event group was spanned across multiple
       relay log files, a slave could incorrectly identify
       GTID-header group boundaries. This meant that when a
       transaction was retried, or if the SQL thread was stopped in
       the middle of a transaction after some rotates, the
       Gtid_log_event was being silently skipped on the slave, and
       the transaction was logged with the slave's GTID. This problem
       also impacted on using START SLAVE UNTIL MASTER_LOG_POS =
       log_pos; with GTIDs enabled. If log_pos was in the middle of a
       transaction, the Gtid_log_event was not correctly detected as
       the beginning of the transaction and replication stopped
       before this event. With this fix, threads correctly detect
       that they are part of a group, and this is used to check if a
       Gtid_log_event is part of a transaction. (Bug #72313, Bug
       #18652178, Bug #18306199)

     * Replication: The error messages generated when a duplicate
       server UUID causes issues during replication have been
       improved. The slave error now identifies the duplicate server
       UUID and the master error identifies the zombie thread that
       has been killed. (Bug #72578, Bug #18731211)

     * Replication: Replication of tables that contained temporal
       type fields (such as TIMESTAMP, DATETIME, and TIME) from
       different MySQL versions failed due to incompatible TIMESTAMP
       types. The fractional TIMESTAMP format added in MySQL 5.6.4
       was not being correctly converted. You can now replicate a
       TIMESTAMP in either format correctly according to the
       slave_type_conversions variable. (Bug #70124, Bug #17532932)

     * Replication: The CLIENT_REMEMBER_OPTIONS flag for compressed
       slave connections is no longer reset and all options are
       retained. This restores functionality of all options to
       compressed slave connections. (Bug #72901, Bug #18923691, Bug
       #73324, Bug #19244772)

     * Replication: When using row-based replication, running a long
       transaction involving a large number of events could trigger
       an Out of Memory (OOM) error if the slave's table structure
       was not compatible with the master's table structure. Such an
       incompatible situation could occur if the table on the slave
       had been manually changed, or when replicating between
       different MySQL versions that have different data types. This
       OOM error was caused because the virtual temporary tables
       created for the row conversion were not being freed until the
       end of the transaction, which was a problem when replicating
       large numbers of events.
       Starting with this version, such virtual tables are correctly
       freed during the conversion process. (Bug #72610, Bug
       #18770469)

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

     * 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 #69954, Bug #17283409)
       References: See also Bug #73475, Bug #19364731, Bug #19365180.

     * Replication: When gtid_mode=ON, and a transaction is filtered
       out on the slave, the GTID of the transaction is still logged
       on the slave as an "empty" transaction (consisting of a GTID
       followed immediately by BEGIN and then COMMIT). This is
       necessary to prevent the transaction from being retransmitted
       the next time the slave reconnects or is involved in a
       failover. The current fix addresses two issues relating to
       such "empty" transactions:

          + No empty transaction was generated for CREATE TEMPORARY
            TABLE or DROP TEMPORARY TABLE statements.

          + If the slave used a database filter (--replicate-do-db or
            --replicate-ignore-db option), no empty transaction was
            generated.
       (Bug #71376, Bug #18095502, Bug #18145032)
Thread
MySQL Community Server 5.7.5 has been released (part 2/3)Bjorn Munch25 Sep