Log Message:
mysql57: updated to 5.7.27

Changes in MySQL 5.7.27:

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.

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.

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.

InnoDB: Manually changing the system time while the MySQL server was running \ 
caused page cleaner thread delays.

InnoDB: During log application, after an OPTIMIZE TABLE operation, InnoDB did \ 
not populate virtual columns before checking for virtual column index updates.

InnoDB: An INSERT operation involving a generated virtual BLOB column resulted a \ 
secondary index being updated with an incorrect value.

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.

InnoDB: Client sessions using different auto_increment_increment values while \ 
performing concurrent insert operations could cause a duplicate key error.

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.

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.

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.

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.

Replication: If a FLUSH LOGS statement was issued before the binary log file was \ 
initialized, the statement attempted to write a binary log rotation event to the \ 
uninitialized file. The server now checks first that a binary log file is \ 
available.

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.

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.

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.

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.

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.

An overly strict assertion could be raised during sorting of stored program \ 
local objects.

Installing from RPM packages could result in an error log with incorrect permissions.

Enabling audit log encryption could cause a server exit.

On Debian and Ubuntu, MySQL packages did not enable mysql.service after upgrades \ 
from native MySQL packages.

The server did not properly close shared-memory connections when an error \ 
occurred, which could result in unexpected server behavior.

MySQL Installer did not install OpenSSL DLL dependencies if the Development \ 
component was not selected.

The parser could leak memory for certain multiple-statement queries.

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.

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.

HANDLER statements did not always work correctly with tables having generated \ 
columns.

Session-tracking information in the client/server protocol could be mishandled.

With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled, password changes failed, with \ 
no warning or error reported.

The audit_log plugin did not log UNINSTALL PLUGIN audit_log statements.

audit_log filtering operations could leak memory.

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.

Privileges for dropping some Performance Schema tables were checked incorrectly.

A query that employed a derived table which included an ORDER BY was not always \ 
handled correctly.

Base columns were not excluded from index-only access by a generated column.

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.

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.

The audit_null plugin did not properly check for a null event record.

UpdateXML() did not always free memory properly in certain cases.

Empty values in the name column of the mysql.plugin system table caused the \ 
server to exit during startup.

With the thread_pool plugin enabled, the Performance Schema status_by_thread \ 
table contained no data.

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

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.

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.