MySQL Community Server 5.7.32 has been released
Posted by: Tvarita Jain
Date: October 19, 2020 08:11AM
Date: October 19, 2020 08:11AM
Dear MySQL users, MySQL Server 5.7.32, a new version of the popular Open Source Database Management System, has been released. MySQL 5.7.32 is recommended for use on production systems. For an overview of what's new in MySQL 5.7, please see https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html For information on installing MySQL 5.7.32 on new servers, please see the MySQL installation documentation at https://dev.mysql.com/doc/refman/5.7/en/installing.html MySQL Server 5.7.32 is available in source and binary form for a number of platforms from our download pages at https://dev.mysql.com/downloads/mysql/ MySQL Server 5.7.32 is also available from our repository for Linux platforms, go here for details: https://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: https://dev.mysql.com/downloads/installer/ 5.7.32 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.: https://bugs.mysql.com/report.php The following link lists the changes in the MySQL 5.7 since the release of MySQL 5.7.31. It may also be viewed online at https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-32.html Enjoy! Changes in MySQL 5.7.32 (2020-10-19, General Availability) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * LOCK TABLES privilege checking for views was improved. (Bug #31304432) Bugs Fixed * InnoDB: A query that updated the clustered index of an internal temporary table returned an incorrect result. The modified pages of the clustered index were not added to the flush list resulting in lost changes when the modified pages were evicted from the buffer pool. (Bug #31560679) References: This issue is a regression of: Bug #29207450. * InnoDB: An ALTER TABLE ... IMPORT TABLESPACE operation on a large encrypted and compressed table failed with a Page decompress failed after reading from disk error. The decryption operation did not use the encryption block size used during encryption. Also, the encryption process did not consider compressed length, while the decryption process decrypts data by compressed length only. (Bug #31313533) * InnoDB: A failure occurred during a concurrent update operation. The failure was due to an invalid previous record value. (Bug #31205266, Bug #99286) * InnoDB: The function used to process the SHOW ENGINE INNODB MUTEX statement was insufficiently isolated from other threads adding new mutexes concurrently. (Bug #31105262) * InnoDB: The buffer control block structure (buf_block_t) was freed while reducing the size of the buffer pool, causing an assertion failure. The fix for this bug also backports important aspects of the fix for Bug #20735882 / Bug #76343, and replaces the internal buf_block_is_uncompressed() function with the buf_pointer_is_block_field_instance() function. The buf_block_is_uncompressed() function returned false in too many cases, affecting OLTP query throughput. (Bug #31036301, Bug #31389823) * InnoDB: In session started with START TRANSACTION WITH CONSISTENT SNAPSHOT, a range query returned a truncated result. The end range flag was not reset at the beginning of the index read resulting in an aborted read and missing rows. (Bug #30950714, Bug #98642) References: This issue is a regression of: Bug #23481444. * InnoDB: A full-text phrase search raised an assertion failure. Thanks to TXSQL (Tencent MySQL) for the contribution. (Bug #30933728, Bug #31228694) References: This issue is a regression of: Bug #22709692. * InnoDB: A long running statistics calculation operation on a large table blocked other operations requiring access to the table's statistics, causing those operations to fail. A new statistics calculation mutex was introduced, which permits concurrent access table statistics. Thanks to Kamil Holubicki for the contribution. (Bug #30607708) * InnoDB: Two connections attempted to use the same transaction handler object resulting in a stalled query. (Bug #30594501) * Replication: When a replication source server shuts down and restarts, its MEMORY tables become empty. To replicate this effect to replicas, the first time that the source uses a given MEMORY table after startup, it logs an event that notifies replicas that the table must be emptied by writing a statement to the binary log to that effect. Previously, this was a DELETE statement, but it is now a TRUNCATE statement. A replica server also writes this statement to its own binary log when it shuts down and restarts. The statement is always logged in statement format, even if the binary logging format is set to ROW, and it is written even if read_only or super_read_only mode is set on the server. (Bug #29848785, Bug #95496) * Replication: When the system variable session_track_gtids was set to OWN_GTID on a multithreaded replica, the replica's performance would degrade over time and begin to lag behind the master. The cause was the buildup of the GTIDs recorded by the replica's worker threads at each transaction commit, which increased the time taken by the worker threads to insert new ones. Session state tracking is now disabled for worker threads on a multithreaded replica. Thanks to Facebook for the contribution. (Bug #29049207, Bug #92964) * Certain cases of successful LDAP authentication could cause the server to hang. (Bug #31661437) * In bootstrapping mode, certain multiple-statement transactions could cause unexpected server behavior. (Bug #31650096) * Sensitive LDAP authentication plugin system variables now display as asterisks when retrieved in SQL statements. (Bug #31388444, Bug #31391864) * After the fix for Bug #81009, privilege checks for truncating Performance Schema tables were too restrictive when read_only or super_read_only were enabled, causing truncation to fail even for users with appropriate table privileges. (Bug #31080309, Bug #99072) References: This issue is a regression of: Bug #81009. * Some INSERT statements were not handled correctly. (Bug #31072198) * Certain prepared statements could cause an unexpected server exit. (Bug #30943963) * mysqlpump object validation included objects in excluded databases. (Bug #30819012) * LDAP authentication plugins enforced CA verification incorrectly, which could result in use of an incorrect CA. (Bug #30220357) * ORDER BY queries were not executed correctly when sort_buffer_length and max_sort_length were set to values which caused the internal limit on the maximum number of keys allowed per sort buffer to be set to 0. (Bug #30175483) * A large number of nested arguments in full-text search query caused an error. (Bug #29929684) * When explicit_defaults_for_timestamp was disabled and a NULL was inserted into a generated column declared as TIMESTAMP NOT NULL, the server would attempt to convert the inserted value to CURRENT_TIMESTAMP. Such an insertion is now rejected with ER_BAD_NULL_ERROR. (Bug #29449518) * An assertion could be raised when the SQL layer passed incorrect information to InnoDB about the type of operation to be performed on a temporary table. (Bug #22503696) On Behalf of MySQL Release Engineering Team, Tvarita Jain
MySQL Community Server 5.7.32 has been released
October 19, 2020 08:11AM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.