The linked OpenSSL library for MySQL Server has been updated to version 1.1.1l. Issues fixed in the new OpenSSL version are described at https://www.openssl.org/news/cl111.txt and at http://www.openssl.org/news/vulnerabilities.html. (Bug #33273138, Bug #33309871)
-
Incompatible Change: For all
SELECT
statements on a view, the query digest was based on the view definition. As a result, different queries had the same digest and aggregated together in the Performance Schema tableevents_statements_summary_by_digest
, so statistics in that table were not usable for distinguishing distinctSELECT
statements.The query digest for each
SELECT
statement on a view now is based on theSELECT
, not the view definition. This enables distinguishing distinctSELECT
statements in theevents_statements_summary_by_digest
table. However, tools that use query digests may need some adjustment to account for this change. For example, MySQL Enterprise Firewall and query rewrite plugins rely on query digests and existing rules for them that are associated with views may need to be updated. (Bug #27540213, Bug #89559, Bug #31761802) -
InnoDB: With undo log truncation enabled (
innodb_undo_log_truncate=ON
), it was possible for a deadlock and eventual failure to occur when an undo log truncate operation was initiated after a version upgrade from MySQL 5.6 to MySQL 5.7.34 or earlier. A patch introduced in MySQL 5.7.35 (Bug #32800020) addressed the deadlock issue for direct upgrades from MySQL 5.6 to MySQL 5.7.35 or later, but the issue persisted for instances that were upgraded from MySQL 5.6 to MySQL 5.7.34 or earlier before they were upgraded to MySQL 5.7.35 or later. To address this issue, problematic pre-5.7.2 rollback segment slots are now identified and reset at startup with messages similar to the following written to the error log:[Note] InnoDB: Found duplicate reference rseg: 33 space: 1 page: 3 [Note] InnoDB: Reset pre-5.7.2 rseg: 1 after duplicate is found.
If pre-5.7.2 rollback segment slots have no undo data to purge, a message similar to the following is emitted:
[Note] InnoDB: Successfully reset 32 pre-5.7.2 rseg slots.
If undo data is found in pre-5.7.2 rollback segment slots, a message similar to the following is emitted recommending a slow shutdown and restart:
[Note] InnoDB: pre-5.7.2 rseg: 2 holds data to be purged. History length: 1. Recommend slow shutdown with innodb_fast_shutdown=0 and restart
(Bug #33181859)
InnoDB: Truncation of an undo tablespace during use by an active transaction raised an assertion failure. The transaction was prematurely marked as complete, permitting the truncation operation. (Bug #33162828)
-
InnoDB: Deleting or updating a row from a parent table initiated a cascading
SET NULL
operation on the child table that set a virtual column value to NULL. The virtual column value should have been derived from the base column value.Thanks to Yin Peng at Tencent for the contribution. (Bug #33053297)
InnoDB: The
InnoDB
recovery process did not recognize that page compression had been applied to data that was being recovered, causing the tablespace data file to increase in size during the redo log apply phase, which could lead to a recovery failure for systems approaching a disk-full state. (Bug #32771259)Replication: The error messages issued by MySQL Replication when GTIDs required for auto-positioning have been purged could be incorrectly assigned or scrambled in some situations. (Bug #32965864)
Replication: The contents of the
gtid_executed
andgtid_purged
GTID sets were not persisted after restoring a dump taken using mysqldump. The dump file sequence has now been changed so that themysql
schema (which contains themysql.gtid_executed
table) is not dropped after thegtid_purged
GTID set is written. A new option--skip-mysql-schema
is added for mysqldump which lets you choose not to drop themysql
schema at all. (Bug #32843447)-
JSON: Conversion of
JSON
values to text caused linear growth of the destination string, resulting in an unnecessarily high number of reallocations. Now this process uses exponential growth instead, to reduce the number of allocations required.This fix originally appeared in MySQL 8.0 and was backported to MySQL 5.7 by Annirudh Prasad, whom we thank for the contribution. (Bug #103790, Bug #32919524)
References: See also: Bug #28949700.
Concurrent insert operations on multiple tables with full-text indexes caused a large number of full-text index synchronization requests, resulting in an out of memory condition. (Bug #32831765, Bug #103523)
-
When a query uses a temporary table for aggregation, the group by item is used as a unique constraint on the temporary table: If the item value is already present, the row is updated; otherwise, a new row is inserted into the temporary table. If the item has a result field or reference item, it evaluated twice, once to check whether the result exists in the temporary table and, if not, again while constructing the row to be inserted. When the group by item was nondeterministic, the result value used to check for existence differed from that with which an insert was attempted, causing the insert to be rejected if the value already existed in the table.
We fix this by using the hash of any nondeterministic items as the unique constraint, so that the hash is evaluated once only. (Bug #32552332)
Quote handling was improved for the
SHOW GRANTS
statement. (Bug #31716706)