MySQL Community Server 5.7.27 has been released

[Surabhi Bhat]

Dear MySQL users,

MySQL Server 5.7.27, a new version of the popular Open Source Database
Management System, has been released. MySQL 5.7.27 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.27 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.27 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.27 is also available from our repository for Linux
platforms, go here for details:

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

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.27 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.26. It may also be viewed online at

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

Enjoy!

==============================================================================
Changes in MySQL 5.7.27 (2019-07-22, General Availability)


     * Keyring Notes

     * Packaging Notes

     * X Plugin Notes

     * Functionality Added or Changed

     * Bugs Fixed

Keyring Notes


     * The keyring_aws plugin has been updated to use the latest
       AWS SDK and so that it works with OpenSSL 1.1.

Packaging Notes


     * Binary packages that include curl rather than linking to
       the system curl library now use curl 7.64.0. (Bug #29357198)

X Plugin Notes


     * On Windows, X Plugin logged some messages that were
       unnecessary or insufficiently informative. The messages have been
       removed or improved as appropriate. (Bug #27839153)

Functionality Added or Changed


     * Microsoft Windows: A new warning message now reminds DBAs
       that connections made using the MySQL named pipe on Windows has
       limited the permissions a connector can request on the named
       pipe.  Previously, the named_pipe_full_access_group system
       variable was set to a value that maps to the built-in Windows
       Everyone group (SID S-1-1-0) by default. However, this group is
       not ideal and should be replaced with a group that restricts its
       membership for connectors that are unable to request fewer
       permissions on the MySQL named pipe.  The new warning is written
       to the error log at startup if the string value assigned to
       named_pipe_full_access_group is '*everyone*' (or the Windows
       System Language equivalent) and named pipes are enabled. In
       addition, the warning is written to the error log and raised to
       the client if the system variable is reset to the Everyone group
       at runtime.

Bugs Fixed


     * InnoDB: Insufficient memory barriers in the rw-lock
       implementation caused deadlocks on ARM.  Thanks to Yibo Cai from
       Arm Technology for the contribution. (Bug #29508001, Bug #94699)

     * InnoDB: Manually changing the system time while the MySQL
       server was running caused page cleaner thread delays.  (Bug
       #29138644, Bug #93708)

     * InnoDB: During log application, after an OPTIMIZE TABLE
       operation, InnoDB did not populate virtual columns before
       checking for virtual column index updates. (Bug #28834208)

     * InnoDB: An INSERT operation involving a generated virtual
       BLOB column resulted a secondary index being updated with an
       incorrect value. (Bug #28652826)

     * InnoDB: A full-text cache lock taken when data is
       synchronized was not released if the full-text cache size
       exceeded the full-text cache size limit. (Bug #25289359)

     * InnoDB: Client sessions using different
       auto_increment_increment values while performing concurrent
       insert operations could cause a duplicate key error. (Bug
       #15851528, Bug #67526) References: Reverted patches: Bug
       #14049391, Bug #65225.

     * Partitioning: ALTER TABLE ... EXCHANGE PARTITION failed
       with the error Non matching attribute 'ROW_FORMAT' between
       partition and table when the partitioned table had partitions
       using different row formats, even when the partition to be
       exchanged used the same row format as the non-partitioned table.
       (Bug #28687608)

     * Replication: The error message that is issued for a
       discrepancy between the number of group members and the
       auto-increment interval incorrectly referred to the
       group_replication_auto_increment_increment system variable,
       instead of the auto_increment_increment system variable. The
       value of auto_increment_increment is changed to the value
       specified by group_replication_auto_increment_increment when
       Group Replication starts, but only if auto_increment_increment
       and auto_increment_offset have their default values, and from
       MySQL 8.0, only in multi-primary mode. The value of
       auto_increment_increment was always the value that was checked
       for the error message, and it has now been corrected to give the
       accurate system variable name. (Bug #29542425)

     * Replication: When events generated by one MySQL server
       instance were written to the binary log of another instance, the
       second server implicitly assumed that the first server supported
       the same number of binary log event types as itself. Where this
       was not the case, the event header was handled incorrectly. The
       issue has now been fixed. Thanks to Facebook for the
       contribution. (Bug #29417234)

     * Replication: In Group Replication, joining members could
       wrongly identify themselves as incompatible with an existing
       replication group even if there were members at the same version
       already in the group, because they checked against all other
       members, including the member at the highest version. Joining
       members also included their own version in the compatibility
       check. Now, joining members only compare themselves with the
       existing group member at the lowest version, and do not count
       their own version. (Bug #29390946)

     * Replication: When a MEMORY table is implicitly deleted on
       a master following a server restart, the master writes a DELETE
       statement to the binary log so that slaves also empty the table.
       This generated event now includes a comment in the binary log so
       that the reason for the DELETE statement is easy to identify.
       Thanks to Daniël van Eeden for the contribution. (Bug #29157796,
       Bug #93771)

     * Replication: With statement-based replication in use, if
       super_read_only was set to ON for a server at the point when a
       no-op transaction was between its UPDATE and COMMIT operations,
       the transaction was written to the binary log and assigned a
       GTID. The transaction is now blocked in this situation. From
       MySQL 8.0, the value of super_read_only cannot be changed while a
       transaction is in progress. (Bug #29009092, Bug #93440)

     * Replication: The group communication engine for Group
       Replication (XCom, a Paxos variant) did not handle out of memory
       errors in an appropriate way. If memory could not be allocated to
       make a copy of the payload for a message, an error was logged but
       the message was still sent, with a null payload. The Group
       Communication System (GCS) on the receiving member discarded the
       message as empty, and the XCom instance on the receiving member
       accepted this action and did not retry, resulting in the message
       effectively being skipped. This caused the GTID set on the
       receiving member to diverge from the group, leading to
       replication errors. XCom now terminates gracefully if it
       experiences an out of memory error, so that this situation cannot
       occur. (Bug #28702320)

     * Replication: In query log events in the binary log, the
       thread ID used for the execution of DROP TABLE and DELETE
       statements was identified incorrectly or not at all. On a
       multi-threaded replication slave, where temporary tables were
       involved (which require the correct thread ID as they are session
       specific), this omission resulted in errors when using
       mysqlbinlog to replay the binary log for point-in-time recovery.
       The thread ID is now set correctly. (Bug #28642318, Bug #92398)

     * Replication: When a slave server logs master status and
       connection information to a table (master_info_repository=TABLE),
       which is the default in MySQL 8.0, the mysql.slave_master_info
       table was not being updated on shutdown if the server was in
       super read only mode (super_read_only=ON). No error was written
       to the error log at this time, but replication failed after
       server startup because the master log file and master log
       position information was out of date. The thread that updates the
       master info log at shutdown is now excluded from read-only checks
       like other replication threads are, so it can update the table
       even if the server is in super read only mode. Error handling for
       a slave that is shutting down has also been improved so that any
       failure to write to the slave status logs results in an error in
       the error log. (Bug #27675107, Bug #89987)

     * An overly strict assertion could be raised during sorting
       of stored program local objects. (Bug #29759547, Bug #95062)

     * Installing from RPM packages could result in an error log
       with incorrect permissions. (Bug #29702462)

     * Enabling audit log encryption could cause a server exit.
       (Bug #29549327)

     * On Debian and Ubuntu, MySQL packages did not enable
       mysql.service after upgrades from native MySQL packages.  (Bug
       #29435592)

     * The server did not properly close shared-memory
       connections when an error occurred, which could result in
       unexpected server behavior. (Bug #29435426)

     * MySQL Installer did not install OpenSSL DLL dependencies
       if the Development component was not selected. (Bug #29423421,
       Bug #94168)

     * The parser could leak memory for certain
       multiple-statement queries. (Bug #29419820)

     * CREATE USER and ALTER USER did not check the validity of
       a hashed authentication string when used with IDENTIFIED WITH
       auth_plugin AS 'hash_string' syntax. (Bug #29395944)

     * For InnoDB tables that contained an index on a VARCHAR
       column and were created prior to MySQL 5.7.23, some simple ALTER
       TABLE statements that should have been done in place were
       performed with a table rebuild after an upgrade to MySQL 5.7.23
       or higher. (Bug #29375764, Bug #94383)

     * HANDLER statements did not always work correctly with
       tables having generated columns. (Bug #29300049)

     * Session-tracking information in the client/server
       protocol could be mishandled. (Bug #29297652)

     * With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled,
       password changes failed, with no warning or error reported. (Bug
       #29287785)

     * The audit_log plugin did not log UNINSTALL PLUGIN
       audit_log statements. (Bug #29248047)

     * audit_log filtering operations could leak memory. (Bug
       #29201747)

     * An index defined on a virtual generated column could fail
       to be updated if the column had a base column in a foreign key
       relationship. (Bug #29127203, Bug #93670)

     * Privileges for dropping some Performance Schema tables
       were checked incorrectly. (Bug #29010031)

     * A query that employed a derived table which included an
       ORDER BY was not always handled correctly. (Bug #28942965)

     * Base columns were not excluded from index-only access by
       a generated column. (Bug #28652733) References: See also: Bug
       #29664369. This issue is a regression of: Bug #23169112.

     * A thread pool group could be blocked when a thread
       process tick time exceeded the maximum permitted value.  The tick
       time now uses a larger data type to permit larger values. (Bug
       #28072609)

     * MySQL does not support OpenSSL session tickets, but did
       not set the SSL_OP_NO_TICKET flag to inform OpenSSL of that. The
       flag is now set. (Bug #27655493)

     * The audit_null plugin did not properly check for a null
       event record. (Bug #27638290)

     * UpdateXML() did not always free memory properly in
       certain cases. (Bug #27312862)

     * Empty values in the name column of the mysql.plugin
       system table caused the server to exit during startup.  (Bug
       #27302459)

     * With the thread_pool plugin enabled, the Performance
       Schema status_by_thread table contained no data. (Bug #25933891)

     * If an INSTALL PLUGIN statement contained invalid UTF-8
       characters in the shared library name, it caused the server to
       hang (or to raise an assertion in debug builds). (Bug #14653594,
       Bug #23080148, Bug #27167197)

     * Inner tables of different semijoin nests were interleaved
       during materialization, which could lead to a different result
       for the same query when it used a different query plan. To keep
       this from occurring, a check is added to prevent such
       interleaving. (Bug #92809, Bug #28835179)

     * A query involving GROUP BY on a TIMESTAMP column resulted
       in a duplicate entry for key (ER_DUP_ENTRY) error. This problem
       arose when TIMESTAMP values were inserted into a table using a
       given setting for the time zone and these values were later
       fetched after the time zone setting had been changed, such that
       at least some of the inserted TIMESTAMP values occurred during
       the hour that the time changed from standard to daylight time
       (DST) in the new time zone, during which time the same TIMESTAMP
       value can exist twice. Now, when the server would otherwise
       return the error DUPLICATE ENTRY FOR KEY 'group_key', if the
       grouping involves a TIMESTAMP column, it instead raises the error
       Grouping on temporal is non-deterministic for time zones having
       DST. Please consider switching to UTC for this query.  In
       addition, it is suggested to set explicit_defaults_for_timestamp
       to ON as well as one or more of MODE_NO_ZERO_IN_DATE,
       MODE_NO_ZERO_DATE, or MODE_INVALID_DATES as part of the server
       SQL mode to help avoid this issue. (Bug #90398, Bug #27970159)

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat