MySQL 5.7 Release Notes

10 Changes in MySQL 5.7.36 (2021-10-19, General Availability)

Security Notes

Bugs Fixed

  • 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 table events_statements_summary_by_digest, so statistics in that table were not usable for distinguishing distinct SELECT statements.

    The query digest for each SELECT statement on a view now is based on the SELECT, not the view definition. This enables distinguishing distinct SELECT statements in the events_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 and gtid_purged GTID sets were not persisted after restoring a dump taken using mysqldump. The dump file sequence has now been changed so that the mysql schema (which contains the mysql.gtid_executed table) is not dropped after the gtid_purged GTID set is written. A new option --skip-mysql-schema is added for mysqldump which lets you choose not to drop the mysql 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)