MySQL Community Server 5.7.29 has been released

[Surabhi Bhat]

Dear MySQL users,

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

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

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

For information on installing MySQL 5.7.29 on new servers, please see
the MySQL installation documentation at

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

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

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

MySQL Server 5.7.29 is also available from our repository for Linux
platforms, go here for details:

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

Windows packages are available via the Installer for Windows or .ZIP
(no-install) packages for more advanced needs. The point and click
configuration wizards and all MySQL products are available in the
unified Installer for Windows:

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

5.7.29 also comes with a web installer as an alternative to the full
installer.

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

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

 http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 5.7 since the release
of MySQL 5.7.28. It may also be viewed online at

 http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-29.html

Enjoy!


==============================================================================
Changes in MySQL 5.7.29 (2020-01-13, General Availability)


     * Audit Log Notes

     * Bugs Fixed

Audit Log Notes


     * ANALYZE TABLE statements now produce read audit events.
       (Bug #29625461)

Bugs Fixed


     * InnoDB: os_file_get_parent_dir warnings were encountered
       when compiling MySQL with GCC 9.2.0. (Bug #30499288, Bug #97466)

     * InnoDB: An internal function
       (btr_push_update_extern_fields()) used to fetch newly added
       externally stored fields and update them during a pessimistic
       update or when going back to a previous version of a record was
       no longer required. Newly added externally stored fields are
       updated by a different function. Also, the method used to
       determine the number of externally stored fields was corrected.
       (Bug #30342846)

     * InnoDB: A comparison function found two records to be
       equal when attempting to merge non-leaf pages of a spatial index.
       The function was unable to handle this unexpected condition,
       which resulted in a long semaphore wait and an eventual assertion
       failure. (Bug #30287668)

     * InnoDB: Importing a tablespace from a location outside of
       the data directory raised an assertion failure. (Bug #30190227)

     * InnoDB: Importing a tablespace with a data directory
       definition that did not match the destination data directory
       returned an insufficiently descriptive schema mismatch error.
       (Bug #30190199)

     * InnoDB: Criteria used by the btr_cur_will_modify_tree()
       function, which detects whether a modifying record needs a
       modifying tree structure, was insufficient. (Bug #30113362)

     * InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation
       caused a hang condition. (Bug #29942556, Bug #30324703)

     * InnoDB: A code regression was addressed by prohibiting
       unnecessary implicit to explicit secondary index lock conversions
       for session temporary tables. (Bug #29718243)

     * InnoDB: A tablespace import operation raised an assertion
       when the cursor was positioned on a corrupted page while purging
       delete-marked records. Instead of asserting when encountering a
       corrupted page, the import operation is now terminated and an
       error is reported. (Bug #29454828, Bug #94541)

     * Replication: When a member is joining or rejoining a
       replication group, if Group Replication detects an error in the
       distributed recovery process (during which the joining member
       receives state transfer from an existing online member), it
       automatically switches over to a new donor, and retries the state
       transfer. The number of times the joining member retries before
       giving up is set by the group_replication_recovery_retry_count
       system variable. The Performance Schema table
       replication_applier_status_by_worker displays the error that
       caused the last retry. Previously, this error was only shown if
       the group member was configured with parallel replication applier
       threads (as set by the slave_parallel_workers system variable).
       If the group member was configured with a single applier thread,
       the error was cleared after each retry by an internal RESET SLAVE
       operation, so it could not be viewed. This was also the case for
       the output of the SHOW SLAVE STATUS command whether there were
       single or multiple applier threads.  The RESET SLAVE operation is
       now no longer carried out after retrying distributed recovery, so
       the error that caused the last retry can always be viewed. (Bug
       #30517160, Bug #30517172)

     * Replication: A memory leak could occur when a failed
       replication group member tried to rejoin a minority group and was
       disallowed from doing so. (Bug #30162547, Bug #96471)

     * Replication: If a replication slave was set up using a
       CHANGE MASTER TO statement that did not specify the master log
       file name and master log position, then shut down before START
       SLAVE was issued, then restarted with the option
       --relay-log-recovery set, replication did not start. This
       happened because the receiver thread had not been started before
       relay log recovery was attempted, so no log rotation event was
       available in the relay log to provide the master log file name
       and master log position.  In this situation, the slave now skips
       relay log recovery and logs a warning, then proceeds to start
       replication.  (Bug #28996606, Bug #93397)

     * Replication: When GTIDs are enabled on a replication
       master and slave, and the slave connects to the master with the
       MASTER_AUTO_POSITION=1 option set, the master must send the slave
       all the transactions that the slave has not already received,
       committed, or both. If any of the transactions that should be
       sent by the master have been already purged from the master's
       binary log, the master sends the error
       ER_MASTER_HAS_PURGED_REQUIRED_GTIDS (1789) to the slave, and
       replication does not start.  The message provided for the error
       ER_MASTER_HAS_PURGED_REQUIRED_GTIDS has been changed to provide
       advice on the correct action in this situation, which is for the
       slave to replicate the missing transactions from another source,
       or for the slave to be replaced by a new slave created from a
       more recent backup. The message advises that the master's binary
       log expiration period can be revised to avoid the situation in
       future. In addition, the master now identifies the GTIDs of the
       purged transactions and supplies them in its error log in the
       warning message ER_FOUND_MISSING_GTIDS (11809), so that you do
       not need to calculate the missing GTIDs manually. (Bug #26004541,
       Bug #29769293)

     * macOS: On macOS, configuring MySQL with -DWITH_SSL=system
       caused mysql_config output to incorrectly include internal CMake
       names for the static SSL libraries. (Bug #30541879, Bug #97632)

     * Docker packages were missing the LDAP authentication
       plugins. (Bug #30465247)

     * The original table name for a field in a derived table
       was not always displayed correctly. (Bug #30362898) References:
       See also: Bug #24611344. This issue is a regression of: Bug
       #22364401.

     * MySQL Installer was unable to uninstall MySQL 5.7 on
       Windows Server 2012. (Bug #30323924, Bug #96940)

     * With multiple sessions executing concurrent INSERT ... ON
       DUPLICATE KEY UPDATE statements into a table with an
       AUTO_INCREMENT column but not specifying the AUTO_INCREMENT
       value, inserts could fail with a unique index violation. (Bug
       #30194841, Bug #96578)

     * With lower_case_table_names=2, SHOW TABLES could fail to
       display tables with uppercase names. (Bug #29957361)

     * With keyring_encrypted_file_password set on the command
       line at server startup, the password value could be visible to
       system utilities. (Bug #29848634)

     * With a LOCK TABLES statement in effect, a metadata change
       for the locked table could cause Performance Schema or SHOW
       queries for session variables to hang in the opening_tables
       state. (Bug #29836204, Bug #92387)

     * A SELECT using a WHERE condition of the form A AND (B OR
       C [OR ...]) resulting in an impossible range led to an unplanned
       exit of the server. (Bug #29770705)

     * For JSON-format audit logging, the id field now may
       contain values larger than 65535. Previously, with heaving
       logging activity, more than 65536 queries per second could be
       executed, exceeding the 16 bits permitted for id values. (Bug
       #29661920)

     * An incomplete connection packet could cause clients not
       to properly initialize the authentication plugin name.  (Bug
       #29630767)

     * Client programs that used the libmysqlclient C client
       library could exit upon receipt of an OK packet containing
       malformed session-tracking information. (Bug #29297620, Bug
       #29630735)

     * Under certain conditions, enabling the read_only or
       super_read_only system variable did not block concurrent DDL
       statements executed by users without the SUPER privilege. (Bug
       #28438114, Bug #91852)

     * mysqlpump exits rather than dumping databases that
       contain an invalid view, by design, but it also failed if an
       invalid view existed but was not in any of the databases to be
       dumped. (Bug #27096081)


On Behalf of MySQL Release Engineering Team,
Surabhi Bhat