Path to this page:
Subject: CVS commit: pkgsrc/databases
From: Adam Ciarcinski
Date: 2019-08-06 08:56:43
Message id: 20190806065643.F2C87FBF4@cvs.NetBSD.org
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.
Files: