MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Bjorn Munch Date:September 21 2013 4:10pm
Subject:MySQL Community Server 5.7.2 has been released (part 3 of 4)
View as plain text  
     * InnoDB: During a transaction commit, prepare_commit_mutex is
       acquired to preserve the commit order. If the commit operation
       failed, the transaction would be rolled back but the mutex
       would not be released. Subsequent insert operations would not
       be able to acquire the same mutex. This fix frees
       prepare_commit_mutex during innobase_rollback. (Bug #16513588)

     * InnoDB: The row0purge.h include file contained a
       self-referencing inclusion. (Bug #16521741)

     * InnoDB: The InnoDB memcached test.demo_test table would fail
       to work when defined as a utf8 charset table. (Bug #16499038)

     * InnoDB: This fix replaces the IB_ULONGLONG_MAX constant with
       LSN_MAX where the code refers to log sequence numbers, or with
       TRX_ID_MAX where trx->no is initialized to an undefined value.
       This change does not alter the value of the constant. (Bug

     * InnoDB: This fix corrects the text for InnoDB error 6025,
       which stated, "InnoDB: read can't be opened in ./ib_logfile0
       mode.". The corrected message states, "InnoDB: ./ib_logfile0
       can't be opened in read mode." The variable and mode in the
       message construct were transposed. (Bug #16434398)

     * InnoDB: The page_zip_available function would count some
       fields twice. (Bug #16463505)

     * InnoDB: This fix removes most calls to OS_THREAD_SLEEP from
       InnoDB. (Bug #16472953, Bug #68588)

     * InnoDB: Concurrently inserting into a full-text table would
       cause some inserts to fail. Duplicate values would be
       generated for full-text search document IDs when performing
       inserts into a hidden full-text search document ID column.
       (Bug #16469399)

     * InnoDB: FLUSH TABLES FOR EXPORT would sleep too often while
       flushing pages from buffer pools. (Bug #16471701)

     * InnoDB: In cases where threads are forced to do single page
       flushing, fsync() would be triggered for all data files. This
       fix allows for synchronous single page flushing. (Bug

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

     * InnoDB: An InnoDB memcached file descriptor leak would cause a
       serious error. (Bug #16466664)

     * InnoDB: In debug builds, an insert would fail with an invalid
       assertion: sync_thread_levels_g(array, level - 1, TRUE). (Bug

     * InnoDB: Multiple concurrent calls to dict_update_statistics()
       would result in unnecessary server load. (Bug #16400412)

     * InnoDB: On 64-bit Windows builds, INNODB_BUFFER_POOL_SIZE
       would not accept an allocation of more than 32GB. This
       limitation was due to a bug that truncated the internal value
       for the InnoDB buffer pool size to 32 bits on 64-bit Windows
       builds. (Bug #16391722, Bug #68470)

     * InnoDB: An ALTER TABLE operation that performed a table copy
       failed because a temporary tablespace with the same name
       already existed. This fix makes temporary tables and
       tablespace names more unique by adding the current log
       sequence number (LSN) to the end of the previous table or file
       name. For example, table name "test/#sql-ib21" becomes
       "test/#sql-ib21-1701208," where 1701208 is the current LSN.
       Both the LSN and the table ID are needed to ensure that the
       name is unique because it is theoretically possible for
       multiple threads to have the same LSN. Including the table ID
       allows the temporary name to be associated with the table.
       (Bug #16403420)

     * InnoDB: Crash recovery would fail with a !recv_no_log_write
       assertion when reading a page. (Bug #16405422)

     * InnoDB: Restarting InnoDB in read-only mode and running a
       workload would occasionally return a global_segment <
       os_aio_n_segments assertion. (Bug #16362046)

     * InnoDB: When the InnoDB shutdown mode (innodb_fast_shutdown)
       is set to 2 and the master thread enters the flush loop, the
       thread would not be able to exit under some circumstances.
       This could lead to a shutdown hang. (Bug #16411457)

     * InnoDB: Creating a foreign key constraint using the ALTER
       TABLE INPLACE algorithm requires foreign_key_checks to be set
       to 0 (SET foreign_key_checks = 0;). As a result, an
       appropriate duplicate ID check would not be performed. (Bug

     * InnoDB: This fix removes dated and incomplete code that is
       protected by the UNIV_LOG_ARCHIVE macro. (Bug #16296837)

     * InnoDB: RENAME TABLE would result in a hang due to a MySQL
       mutex acquisition deadlock. (Bug #16305265)

     * InnoDB: DROP DATABASE failed if the database contained an
       InnoDB table that had a data file in an external data
       directory. The external data file had an "InnoDB Symbolic
       Link" file type (.isl) that was not recognized by MySQL. This
       fix adds .isl as a known InnoDB file type. (Bug #16338667)

     * InnoDB: When tables are linked by foreign key constraints,
       loading one table would open other linked tables recursively.
       When numerous tables are linked by foreign key constraints,
       this would sometimes lead to a thread stack overflow causing
       the server to exit. Tables linked by foreign key constraints
       are now loaded iteratively. Cascade operations, which were
       also performed in a recursive manner, are now performed
       iteratively using an explicit stack. (Bug #16244691, Bug

     * InnoDB: Under testing, a FLUSH TABLE operation resulted in a
       timeout due to a missing acknowledgement that the purge thread
       had stopped. (Bug #16277387)

     * InnoDB: For a compressed table, the "page reorganize" function
       would ignore the innodb_log_compressed_pages option and always
       log the entire compressed page, which increased the size of
       the redo log. The "page reorganize" function now adheres to
       the innodb_log_compressed_pages option and does not log
       compressed page images to the redo log when
       innodb_log_compressed_pages is set to "OFF". (Bug #16267120)

     * InnoDB: After disabling foreign key checks with SET
       foreign_key_checks=0 and performing a DROP INDEX, the table
       was no longer accessible after restarting the server. This fix
       allows the table with missing foreign key indexes to be
       accessed when SET foreign_key_checks=0. When the table is
       accessible, the user must recreate the missing indexes to
       fulfill the foreign key constraints. (Bug #16208542, Bug

     * InnoDB: When a transaction is in READ COMMITTED isolation
       level, gap locks are still taken in the secondary index when a
       row is inserted. This occurs when the secondary index is
       scanned for duplicates. The function
       row_ins_scan_sec_index_for_duplicate() always calls the
       function row_ins_set_shared_rec_lock() with LOCK_ORDINARY
       irrespective of the transaction isolation level. This fix
       modifies the row_ins_scan_sec_index_for_duplicate() function
       to call row_ins_set_shared_rec_lock() with LOCK_ORDINARY or
       LOCK_REC_NOT_GAP, based on the transaction isolation level.
       (Bug #16133801, Bug #68021)

     * InnoDB: Starting mysqld with --innodb_log_buffer_size=50GB
       failed to allocate memory and returned NULL. For non-debug
       builds there was no check in place and a segmentation fault
       occurred. This fix adds a log message stating that memory
       failed to be allocated, and adds an assertion. (Bug #16069598,
       Bug #68025)

     * InnoDB: When UNIV_DEBUG is enabled in debug builds,
       buf_validate() is often called which sometimes results in
       false alarms in tests on semaphore wait timeout. This fix
       increases counter values to reduce false alarms. (Bug

     * InnoDB: While processing read-write workloads, InnoDB would
       scan more pages than are required for flushing, unnecessarily
       consuming CPU resource. (Bug #16037180)

     * InnoDB: The explain_filename function, which provides
       information about a partition by parsing the file name, would
       return an error when attempting to parse a file name with no
       partition information. (Bug #16051728)

     * InnoDB: Stopping the server, removing a database table (d1.t1)
       .frm file from the data directory, restarting the server, and
       dropping the database (d1), would cause an assertion. (Bug

     * InnoDB: While printing a UTF-8 table name, InnoDB would
       truncate the table name, resulting in an incomplete buffer and
       subsequent Valgrind error. This bug fix also addresses an
       incorrect debugging error message. (Bug #16066351)

     * InnoDB: TRUNCATE TABLE would fail to handle the return value
       from btr_create when btr_create is invoked by TRUNCATE TABLE
       for creation of a new index. (Bug #16026889)

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

     * InnoDB: An overflow would occur for innodb_row_lock_time_max
       and innodb_row_lock_current_waits. This fix modifies code
       logic in storage/innobase/srv/srv0srv.c. (Bug #16005310)

     * InnoDB: Attempting to create a table while in innodb_read_only
       mode would result in the following error: ERROR 1015 (HY000):
       Can't lock file (errno: 165 - Table is read only). (Bug

     * InnoDB: An active FLUSH TABLE FOR EXPORT thread would cause a
       hang during shutdown. The fix ensures that
       trx_is_interrupted() is checked during ibuf_merge. (Bug

     * InnoDB: innochecksum would return an error when run on
       compressed tables. (Bug #14612872, Bug #66779)

     * InnoDB: A multi-row INSERT ... ON DUPLICATE KEY UPDATE insert
       failure, caused by a duplicate key error, would result in
       duplicate auto-increment values. (Bug #14483484, Bug #66301)

     * InnoDB: A mismatch between .ibd files and the InnoDB data
       dictionary could occur if TRUNCATE TABLE is interrupted by a
       crash. The mismatch would be encountered after recovery. To
       avoid this problem, truncate table information is written to a
       truncate log file that resides temporarily in the log
       directory. The truncate log file has the following naming
       convention: ib_space_id_trunc.log. If the truncate TRUNCATE
       operation is successful, the truncate log file is removed. If
       the TRUNCATE operation is interrupted by a crash, information
       is read from the truncate log file during recovery, the log
       records are applied, and the truncate log file is removed.
       (Bug #14174004, Bug #13997329, Bug #17227149, Bug #17238361)

     * InnoDB: The documentation incorrectly stated that START
       snapshot only if the current isolation level is REPEATABLE
       SNAPSHOT only works with REPEATABLE READ. All other isolation
       levels are ignored. The documentation has been revised and a
       warning is now generated whenever the WITH CONSISTENT SNAPSHOT
       clause is ignored. (Bug #14017206, Bug #65146)

     * InnoDB: The srv_master_thread background thread, which
       monitors server activity and performs activities such as page
       flushing when the server is inactive or in a shutdown state,
       runs on a one second delay loop. srv_master_thread would fail
       to check if the server is in a shutdown state before sleeping.
       (Bug #13417564, Bug #63276)

     * InnoDB: In the error log, a full-text search index would be
       reported missing from the data dictionary during a TRUNCATE
       TABLE operation. After restarting mysqld, the following InnoDB
       error would be reported: "InnoDB: Error: trying to load index
       idx13 for table test/g1 but the index tree has been freed.."
       (Bug #12429565)

     * InnoDB: Compiling InnoDB on Windows Vista 64-bit with VS2005
       would result in compilation errors. (Bug #11752731, Bug

     * InnoDB: When the value provided for innodb_buffer_pool_size on
       32-bit systems is too large, an error message would
       incorrectly reference the internal variable,
       innobase_buffer_pool_size, instead of innodb_buffer_pool_size.
       (Bug #11759578, Bug #51901)

     * InnoDB: In many cases InnoDB calls exit(1) when it encounters
       a fatal error. An exit(1) call does not produce a crash dump
       or provide information about the process state. Additionally,
       on Windows, an exit(1) call does not report a crashed process
       in the Event Viewer. This fix replaces exit(1) calls with
       ut_error calls in a number of places. (Bug #56400, Bug

     * InnoDB: Creating a table with a comment or default textual
       value containing an apostrophe that is escaped with a
       backslash would sometimes cause the InnoDB storage engine to
       omit foreign key definitions. (Bug #61656, Bug #12762377)

     * InnoDB: Setting foreign_key_checks=0 and running ALTER TABLE
       to change the character set of foreign key columns for a
       database with multiple tables with foreign key constraints
       would leave the database in an inconsistent state. Subsequent
       ALTER TABLE operations (using the COPY algorithm) with
       foreign_key_checks=1 would fail due to the detected
       inconsistency. Reversion of the partially executed ALTER TABLE
       operation would also fail, resulting in the loss of the table
       being altered. When running the same ALTER TABLE operation
       with a RENAME clause, the inconsistency would not be detected
       but if the ALTER TABLE operation failed for some other reason,
       reversion of the partially executed ALTER TABLE would fail
       with the same result.
       The bug fix temporarily disables foreign_key_checks while the
       previous table definition is restored. (Bug #65701, Bug

     * InnoDB: Successive deletes in descending key order would lead
       to under-filled InnoDB index pages. When an InnoDB index page
       is under-filled, it is merged with the left or right sibling
       node. The check performed to determine if a sibling node is
       available for merging was not functioning correctly. (Bug
       #68501, Bug #16417635)

     * InnoDB: The pthread_mutex, commit_threads_m, which was
       initialized but never used, has been removed from the code
       base. (Bug #60225, Bug #11829813)

     * InnoDB: When running an InnoDB full-text search in boolean
       mode, prefixing an asterisk (*) to a search string ('*string')
       would result in an error whereas for MyISAM, a prefixed
       asterisk would be ignored. To ensure compatibility between
       InnoDB and MyISAM, InnoDB now handles a prefixed asterisk in
       the same way as MyISAM. (Bug #68948, Bug #16660607)

     * InnoDB: The row_check_index_for_mysql method, which checks for
       NULL fields during an index scan or CHECK TABLE operation,
       would iterate unnecessarily. Thanks to Po-Chun Chang for the
       patch to correct this issue. (Bug #69377, Bug #16896647)

     * Partitioning: When upgrading to MySQL 5.5.31 or higher, a
       message is written into the output of mysql_upgrade when
       encountering a partitioned table for which the ALGORITHM
       option is required to maintain binary compatibility with the
       original; the message includes the ALTER TABLE statement
       required to make the change. For such a table having a
       sufficiently large number of partitions, the message was
       truncated with an error before the complete ALTER TABLE
       statement could be written. (Bug #16589511)

     * Partitioning: When a range specified in the WHERE condition of
       a query against a table partitioned by RANGE entirely within
       that of one of the partitions, the next partition was also
       checked for rows although it should have been pruned away.
       Suppose we have a range-partitioned table t created using the
       following SQL statement:
    dt DATETIME,
    PRIMARY KEY (dt,id),
    UNIQUE KEY (id,dt)
        PARTITION p0 VALUES LESS THAN ('2013-01-01'),
        PARTITION p1 VALUES LESS THAN ('2013-01-15'),
        PARTITION p2 VALUES LESS THAN ('2013-02-01'),
        PARTITION p3 VALUES LESS THAN ('2013-02-15'),
       An example of a query that exhibited this issue when run
       against t is shown here:
    WHERE dt >= '2013-02-01' AND dt < '2013-02-15';
       In this case, partition pmax was checked, even though the
       range given in the WHERE clause lay entirely within partition
       p3. (Bug #16447483)

     * Partitioning: When dropping a partitioned table, the table's
       .par file was deleted first, before the table definition or
       data. This meant that, if the server failed during the drop
       operation, the table could be left in an inconsistent state in
       which it could neither be accessed nor dropped.
       The fix for this problem makes the following changes:

          + Now, when dropping a partitioned table, the table's .par
            file is not removed until all table data has been

          + When executing DROP TABLE of a partitioned table, in the
            event that its .par file is determined to be missing, the
            table's .frm file is now immediately deleted, in effect
            forcing the drop to complete.
       (Bug #13548704, Bug #63884)

     * Replication: The data size for a table map event created
       during execution was calculated, but not when the event was
       created from a network packet. This could later cause problems
       when the data fields of such events were treated as if they
       had a length equal to 0 when trying to write the events to a
       cache, or to the binary log.
       To avoid future problems of this nature, the table map's data
       size is now calculated in both cases. (Bug #17164074)

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

     * Replication: The mysqlbinlog option --rewrite-db caused USE
       statements to be ignored, even for databases that were not
       referenced by the option. (Bug #16914535)

     * Replication: The condition leading to the issue fixed in Bug
       #16579083 continued to raise an error even though the
       condition itself no longer cause the issue to occur. (Bug
       #16931177, Bug #69369)
       References: See also Bug #16271657, Bug #16491597, Bug #68251,
       Bug #68569.

     * Replication: When rpl_semi_sync_master_timeout was set to an
       extremely large value, semi-synchronous replication became
       very slow, especially when many sessions were working in
       parallel. It was discovered that the code to calculate this
       timeout was inside the wait loop itself, with the result that
       an increase in the value of rpl_semi_sync_master_timeout
       caused repeated iterations. This fix improves the method used
       to calculate wakeup times, and moves it outside of the wait
       loop, so that it is executed one time only. (Bug #16878043,
       Bug #69341)

     * Replication: It was possible to cause a deadlock after issuing
       FLUSH TABLES WITH READ LOCK by issuing STOP SLAVE in a new
       connection to the slave, then issuing SHOW SLAVE STATUS using
       the original connection.
       The fix for this includes the addition of the
       rpl_stop_slave_timeout system variable, to control the time in
       seconds to wait for slave to stop after issuing STOP SLAVE
       before returning a warning. (Bug #16856735)

     * Replication: Some expressions employing variables were not
       handled correctly by LOAD DATA. (Bug #16753869)

     * Replication: In some circumstances, the message in the
       Last_Error column from the output of SHOW SLAVE STATUS
       referred to GTID_NEXT_LIST although this variable is not
       currently implemented (the name is reserved for possible
       future use). Now in such cases the error message no longer
       refers to this variable. (Bug #16742886, Bug #69096)
       References: See also Bug #16715809, Bug #69045.

     * Replication: Point-in-time recovery could fail when trying to
       restore a single database from a binary log in row-based
       format using mysqlbinlog with the --database option. (Bug

     * Replication: mysqlbinlog --rewrite-db failed when the name of
       the destination database contained any underscore (_)
       characters. (Bug #16737279)

     * Replication: Issuing a FLUSH TABLES statement on a
       GTID-enabled master caused replication to fail. It was found
       that this misbehavior was introduced by the fix for Bug
       #16062608, which disallowed statements that perform an
       implicit commit but whose changes are not logged when
       gtid_next is set to any value other than AUTOMATIC. The
       changes made in that fix have been reverted, and such
       statements are (again) allowed without regard to the value of
       this variable. (Bug #16715809, Bug #69045)

     * Replication: On Windows platforms, issuing SHOW SLAVE STATUS
       while the slave I/O thread was being terminated due to an
       error caused the slave to fail. (Bug #16662771)

     * Replication: A crash-on-commit error caused InnoDB to lose the
       previous transaction following execution of a RESET MASTER
       statement. This occurred because the prepare phase caused a
       flush to disk, while the commit phase did not perform a
       corresponding flush within InnoDB.
       To fix this problem, RESET MASTER now causes storage engine
       logs to be flushed on commit. (Bug #16666456, Bug #68932)

     * Replication: When used with the options --dump-slave
       --include-master-host-port, mysqldump printed the port number
       within quotation marks, as if it were a string value rather
       than an integer. (Bug #16615117)

     * Replication: When processing an Update_rows_log_event or
       Delete_rows_log_event from the binary log, the before image is
       hashed and stored in a hash table. Following this, the
       original table is scanned for the desired records; subsequent
       processing hashes each record fetched from the original table
       and performs a lookup for it in the hash table. However,
       columns read from the image that had originally been set to
       NULL could instead contain random or "garbage" data, causing
       the lookup (and thus replication) to fail with an error such
       as Could not execute Update_rows event on table.... (Bug
       References: See also Bug #11766865. This bug was introduced by
       Bug #16566658.

     * Replication: The error displayed by SHOW SLAVE STATUS when a
       worker thread fails to apply an event contained no event
       coordinate information. The GTID for the event's group was
       also not shown. Now in such cases, the text shown for
       Last_SQL_Error is prefixed with the (physical) master binary
       log coordinates, as well as the value of gtid_next when this
       has been set. (Bug #16594095)

     * Replication: Due to time resolution issues on some systems,
       the time to be taken by the dump thread for a reply from the
       slave could be calculated to be less than zero, leading to
       Semi-sync master wait for reply fail to get wait time errors.
       Since this condition does not have a negative impact on
       replication, errors caused by these conditions have been
       reduced to warnings. (Bug #16579028)

     * Replication: Linker errors occurred if the header file
       log_event.h was included in an application containing multiple
       source files, because the file was included in
       log_event.h. This fix moves the inclusion of
       into the source files that use log_event.h. (Bug #16607258)

     * Replication: When one or more GTID log events but no previous
       GTIDs log events were found in the binary log, the resulting
       error was mishandled and led to a failure of the server. (This
       is an extremely rare condition that should never occur under
       normal circumstances, and likely indicates that the binary log
       file has somehow been corrupted.) Now in such cases, an
       appropriate error is issued, and is handled correctly. (Bug
       #16502579, Bug #68638)

     * Replication: Running the server with --log-slave-updates
       together with --replicate-wild-ignore-table or
       --replicate-ignore-table in some cases caused updates to user
       variables not to be logged. (Bug #16541422)

     * Replication: When using mysqlbinlog and the mysql client to
       roll forward two or more binary logs on a server having GTIDs
       enabled, the gtid_next variable was not properly reset when
       switching from the first to the second binary log, causing
       processing to halt with an error at that point. (Bug

     * Replication: The mysqlbinlog options --include-gtids,
       --exclude-gtids, and --skip-gtids did not work correctly when
       trying to process multiple files. (Bug #16517775)

     * Replication: The warning issued when specifying MASTER_USER or
       MASTER_PASSWORD with CHANGE MASTER TO was unclear for a number
       of reasons, and has been changed to read, Storing MySQL user
       name or password information in the master info repository is
       not secure and is therefore not recommended. Please consider
       using the USER and PASSWORD connection options for START
       SLAVE; see 'START SLAVE Syntax' in the MySQL Manual for more
       information. (Bug #16460123, Bug #16461303, Bug #68602, Bug

     * Replication: When the size of an execution event exceeded the
       maximum set for the buffer (slave_pending_jobs_size_max),
       row-based replication could hang with Waiting for slave
       workers to free pending events. (Bug #16439245, Bug #68462)

     * Replication: Extra binary log rotations were performed due to
       concurrent attempts at rotation when the binary log became
       full, which were allowed to succeed. This could lead to the
       unnecessary creation of many small binary log files. (Bug
       #16443676, Bug #68575)

     * Replication: Attempting to execute START SLAVE after importing
       new slave_master_info and slave_relay_log_info tables failed
       with an empty error message. Now an appropriate error and
       message are issued in such cases. (Bug #16475866, Bug #68605)

     * Replication: Restarting the server after the
       slave_relay_log_info table had been emptied caused mysqld to
       fail while trying to return an error. (Bug #16460978, Bug

     * Replication: Following disconnection from the master, the
       slave could under certain conditions report erroneously on
       reconnection that it had received a packet that was larger
       than slave_max_allowed_packet, causing replication to fail.
       (Bug #16438800, Bug #68490)

     * Replication: An SQL thread error during MTS slave recovery
       caused the slave to fail. (Bug #16407467, Bug #68506)

     * Replication: When using the options --read-from-remote-server
       --stop-never --base64-output=decode-rows --verbose,
       mysqlbinlog failed to reset the counter used to store the
       current position within the file when the binary log on the
       server was rotated. (Bug #16316123, Bug #68347)

     * Replication: When using mysqldump to back up a database
       created with MySQL 5.6.4 or an earlier version, setting
       --set-gtid-purged=AUTO caused the backup to fail, because
       pre-5.6.5 versions of MySQL did not support GTIDs, and it
       could not be determined if GTIDs were enabled for the
       database. This fix makes sure mysqldump does not attempt to
       output a SET @@global.gtid_purged statement when backing up
       any pre-5.6.5 databases. (Bug #16303363, Bug #68314)

     * Replication: After a transaction was skipped due to its GTID
       already having been logged, all remaining executed
       transactions were incorrectly skipped until gtid_next was
       pointed to a different GTID.
       To avoid this incorrect behavior, all transactions---even
       those that have been skipped---are marked as undefined when
       they are commited or rolled back, so that an error is thrown
       whenever a second transaction is executed following the same
       SET @@session.gtid_next statement. (Bug #16223835)

     * Replication: Deadlocks could sometimes occur on group commits
       with a high number of concurrent updates, as well as when one
       client held a lock from a commit while another client imposed
       a lock while rotating the binary log. (Bug #16271657, Bug
       #16491597, Bug #68251, Bug #68569)

     * Replication: Modifying large amounts of data within a
       transaction can cause the creation of temporary files. Such
       files are created when the size of the data modified exceeds
       the size of the binary log cache (max_binlog_cache_size).
       Previously, such files persisted until the client connection
       was closed, which could allow them to grow until they
       exhausted all available disk space in tmpdir. To prevent this
       from occurring, the size of a temporary file created in this
       way in a given transaction is now reset to 0 when the
       transaction is committed or rolled back. (Bug #15909788, Bug

     * Replication: When semisynchronous replication was enabled, the
       automatic dropping on the master of an event created using ON
       COMPLETION NOT PRESERVE caused the master to fail. (Bug
       #15948818, Bug #67276)

     * Replication: When the master had more than one table with an
       auto-increment column, and the slave ignored at least one of
       these tables due to --replicate-ignore-table rules, but at
       least one them was replicated, even so---the replicated table
       or tables having at least one trigger updating one or more
       tables existing only on the slave---updates to any of the
       auto-increment tables on the master caused replication to
       fail. (Bug #15850951, Bug #67504)

     * Replication: Setting a SET column to NULL inside a stored
       procedure caused replication to fail. (Bug #14593883, Bug

     * Replication: The binary log contents got corrupted sometimes,
       because the function MYSQL_BIN_LOG::write_cache always thought
       it had reached the end-of-cache when the function my_b_fill()
       reported a '0,' while that could also mean an error had
       occurred. This fix makes sure that whenever my_b_fill()
       returns a '0,' an error check is performed on info->error.
       (Bug #14324766, Bug #60173)

     * Replication: The internal function
       MYSQL_BIN_LOG::open_binlog() contained an unneeded variable,
       which has been removed. (Bug #14134590, Bug #60188)

     * Replication: PURGE BINARY LOGS by design does not remove
       binary log files that are in use or active, but did not
       provide any notice when this occurred. Now, when log files are
       not removed under such conditions, a warning is issued; this
       warning includes information about the file or files were not
       removed when the statement was issued. (Bug #13727933, Bug

     * Replication: When replicating to a BLACKHOLE table using the
       binary logging format, updates and deletes cannot be applied
       and so are skipped. Now a warning is generated for this
       whenever it occurs.
       binlog_format=STATEMENT is recommended when replicating to
       tables that use the BLACKHOLE storage engine.
       (Bug #13004581)

     * Replication: Temporary files created by LOAD DATA INFILE were
       not removed if the statement failed. (Bug #11763934, Bug

     * Replication: After the client thread on a slave performed a
       FLUSH TABLES WITH READ LOCK and was followed by some updates
       on the master, the slave hung when executing SHOW SLAVE
       STATUS. (Bug #68460, Bug #16387720)

     * Microsoft Windows: On Microsoft Windows, passing in
       --local-service to mysqld.exe when also passing in a service
       name could cause a crash at startup. (Bug #16999777, Bug

     * The contents of SQL condition items such as TABLE_NAME,
       CONSTRAINT_NAME, an so forth were lost if resignaled by a
       stored routine condition handler. (Bug #17280703)

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

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

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

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

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

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

     * Indexed lookups on POINT columns was slower for InnoDB tables
       in MySQL 5.7 compared to 5.6. (Bug #17057168)

     * The Performance Schema was built for embedded server builds.
       This no longer occurs. (Bug #17041705)

     * my_pthread.h unconditionally included pfs_thread_provider.h, a
       noninstalled header file, resulting in compilation failure
       when compiling MySQL applications against the installed header
       files. (Bug #17061480)

     * For debug builds, improper use of SAFE_MUTEX within dbug.c
       caused different code areas to have different ideas about size
       and contents of a mutex. This could result in out-of-bounds
       memory writes. (Bug #16945343)

     * Initialization of keycache_* variables (see Multiple Key
       ml)) during server startup could write to incorrect memory.
       (Bug #16945503)

     * Reads from message buffers for closed connections could occur.
       (Bug #17003702)

     * At server startup, it was possible to set the
       validate_password_length system variable to a value smaller
       than permitted by the values of other password-length
       variables related to it. (Bug #16957721)

     * The server could exit while using a cursor to fetch rows from
       a UNION query. (Bug #16983143)

     * The range optimizer incorrectly assumed that any geometry
       function on a spatial index returned rows in ROWID order,
       which could result in incorrect query results. (Bug #16960800)

     * A race condition in the thread pool plugin could cause status
       variables such as Aborted_connects not to be incremented and
       permitting concurrent kills to happen for the same thread ID.
       (Bug #16959022)

     * mysql_secure_installation did not properly clean up the
       mysql.proxies_privs table for removed accounts. (Bug

     * The server did excessive locking on the LOCK_active_mi and
       active_mi->rli->data_lock mutexes for any SHOW STATUS LIKE
       'pattern' statement, even when the pattern did not match
       status variables that use those mutexes
       (Slave_heartbeat_period, Slave_last_heartbeat,
       Slave_received_heartbeats, Slave_retried_transactions,
       Slave_running). Now attempts to show those variables do not
       lock those mutexes. This might result is slightly stale data,
       but better performance. (Bug #16904035)

     * Full-text phrase search in InnoDB tables could read incorrect
       memory. (Bug #16885178)

     * It was not possible to keep several major versions of MySQL in
       the same yum repository. (Bug #16878042)

     * The Performance Schema could spawn a thread using incorrect
       instrumentation information. (Bug #16939689)

     * The Batched Key Access method could return incorrect results
       on big-endian machines if a table buffered in the BKA join
       cache used a storage engine such as InnoDB or MyISAM with
       little-endian storage format, and then the next table used a
       storage engine such as NDB with native-endian storage format.
       (Bug #16853897)

       string contained a hardcoded database name ('mysql.%s'), which
       is incorrect when the error referred to a table in a different
       database. (Bug #16813605)

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

     * HAVE_REPLICATION now is set from CMake rather than in
       my_global.h so that it is not dependent on my_global.h having
       been included. (Bug #16768511)

     * CMake now assumes the existence of standard C header files
       such as stdlib.h and stdarg.h. (Bug #16748528)

     * Some errors in MySQL 5.7 had different numbers than in MySQL
       5.6. (Bug #16780120)

     * Removing a server RPM package did not shut down the existing
       server if it was running. (Bug #16798868)

     * INSERT ... ON DUPLICATE KEY UPDATE could cause a server exit
       if a column with no default value was set to DEFAULT. (Bug
       References: This bug is a regression of Bug #14789787.

     * An assertion could be raised when the optimizer considered
       pushing down an index condition containing an updatable user
       variable and did not contain fields from the index. (Bug

     * The function fill_locks_row(), which is responsible for
       providing data for the INFORMATION_SCHEMA.INNODB_LOCKS table,
       would try to look up the B-tree page in the buffer pool for
       INFIMUM and SUPREMUM records, both of which have a predefined
       heap_no. This generated unnecessary buffer pool contention and
       caused information to be omitted when a page was not available
       in the buffer pool. This fix removes the buffer pool lookup
       (heap_no=1) from fill_locks_row(). (Bug #16684523)

MySQL Community Server 5.7.2 has been released (part 3 of 4)Bjorn Munch21 Sep