|
Changes in MySQL 5.7.30:
JSON Notes
The rapidjson library included with MySQL has been upgraded to the GitHub snapshot of 16 January 2020. A fix for a compiler error encountered when building from the snapshot on Mac OS X has been added.
Packaging Notes
Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.69.0.
The bundled libedit library was upgraded to version 3.1.
Bugs Fixed
InnoDB: The row_upd_clust_rec_by_insert function, which marks a clustered index record as deleted and inserts an updated version of the record into the clustered index, passed an incorrect n_ext value (the total number of external fields) to lower level functions, causing an assertion failure.
InnoDB: An operation performed with the innodb_buffer_pool_evict debug variable set to uncompressed caused an assertion failure.
InnoDB: An add column operation caused an assertion failure. The failure was due to a dangling pointer.
InnoDB: Updating certain InnoDB system variables that take string values raised invalid read errors during Valgrind testing.
InnoDB: An insert statement on a table with a spatial index raised a record type mismatch assertion due to a tuple corruption.
InnoDB: A function that calculates undo log record size could calculate an incorrect length value in the case of a corrupted undo log record, resulting in a malloc failure. Assertion code was added to detect incorrect calculations.
Replication: While an SQL statement was in the process of being rewritten for the binary log so that sensitive information did not appear in plain text, if a SHOW PROCESSLIST statement was used to inspect the query, the query could become corrupted when it was written to the binary log, causing replication to stop. The process of rewriting the query is now kept private, and the query thread is updated only when rewriting is complete.
Replication: When a GRANT or REVOKE statement is only partially executed, an incident event is logged in the binary log, which makes the replication slave's applier thread stop so that the slave can be reconciled manually with the master. Previously, if a failed GRANT or REVOKE statement was the first statement executed in the session, no GTID was applied to the incident event (because the cache manager did not yet exist for the session), causing an error on the replication slave. Also, no incident event was logged in the situation where a GRANT statement created a user but then failed because the privileges had been specified incorrectly, again causing an error on the replication slave. Both these issues have now been fixed.
Replication: When a replication slave has a generated column that the master does not have in that table, with a secondary index on the generated column, the generated expression should be evaluated and the value stored by the storage engine in the secondary index. When row-based binary logging is in use, the replication slave assigns default values to any fields that are not in the master's definition of the table. In the case of a generated column, which does not have a default value, the slave was previously assigning a null or a zero value to the column. This value was then stored by the storage engine in the secondary index, causing both the table and the index to become corrupted. To fix this issue, generated columns in a table on a replication slave are now re-evaluated before the values are sent to the storage engine.
Replication: In the event of an unplanned disconnection of a replication slave from the master, the reference to the master's dump thread might not be removed from the list of registered slaves, in which case statements that accessed the list of slaves would fail. The issue has now been fixed.
Replication: With the settings binlog_format=MIXED, tx_isolation=READ-COMMITTED, and binlog_row_image=FULL, an INSERT ... SELECT query involving a transactional storage engine omitted any columns with a null value from the row image written to the binary log. This happened because when processing INSERT ... SELECT statements, the columns were marked for inserts before the binary logging format was selected. The issue has now been fixed.
The -libs-compat RPM package is now built with system zlib to avoid problems with unrestricted export of symbols in libmysqlclient.so.18.
The Event Scheduler had a memory leak.
Under certain circumstances, a memcached command could result in reading an uninitialized memory buffer, causing a failure.
Using ALTER USER to reset an account MAX_USER_CONNECTIONS value did not take effect until all current account connections terminated, if there were any.
A materialized subquery including a condition in which a column value was used as input to a nondeterministic function produced incorrect results.
CONCAT() and CONCAT_WS() could produce incorrect results in rare cases due to incorrect substring handling.
Scheduling of events could be disturbed by removing events.
Client programs could load authentication plugins from outside the plugin library.
The server did not handle correctly a UNION in which one of the queries contained a subquery that used ORDER BY.
A query with a WHERE clause whose predicate contained a numeric value in scientific notation was not handled correctly.
In addition, attempting to insert a particular integer specified as a string caused a server exit when the string-to-integer conversion was not successful.
Previously, mysqlpump read the [mysql_dump] and [client] groups from option files. mysqlpump now additionally reads the [mysqlpump] group. The [mysql_dump] group is still accepted but is deprecated.
A multi-table UPDATE statement which updated a table joined to a derived table that joined two other tables was not optimized properly as it had been in MySQL 5.6, instead being treated as if STRAIGHT_JOIN had been used with the subquery creating the derived table.
|
|
Changes in MySQL 5.7.29:
Audit Log Notes
ANALYZE TABLE statements now produce read audit events.
Packaging Notes
Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.66.0.
Bugs Fixed
InnoDB: os_file_get_parent_dir warnings were encountered when compiling MySQL with GCC 9.2.0.
InnoDB: An internal function (btr_push_update_extern_fields()) used to fetch newly added externally stored fields and update them during a pessimistic update or when going back to a previous version of a record was no longer required. Newly added externally stored fields are updated by a different function. Also, the method used to determine the number of externally stored fields was corrected.
InnoDB: A comparison function found two records to be equal when attempting to merge non-leaf pages of a spatial index. The function was unable to handle this unexpected condition, which resulted in a long semaphore wait and an eventual assertion failure.
InnoDB: A tablespace import operation that failed due to the source and destination tables being defined with different DATA DIRECTORY clauses reported an insufficiently descriptive schema mismatch error. Moreover, if a .cfg file was not present, the same operation would raise an assertion failure. A more informative error message is now reported in both cases before the import operation is terminated due to the data directory mismatch.
InnoDB: Criteria used by the btr_cur_will_modify_tree() function, which detects whether a modifying record needs a modifying tree structure, was insufficient.
InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation caused a hang condition.
InnoDB: A code regression was addressed by prohibiting unnecessary implicit to explicit secondary index lock conversions for session temporary tables.
InnoDB: A tablespace import operation raised an assertion when the cursor was positioned on a corrupted page while purging delete-marked records. Instead of asserting when encountering a corrupted page, the import operation is now terminated and an error is reported.
Replication: When a member is joining or rejoining a replication group, if Group Replication detects an error in the distributed recovery process (during which the joining member receives state transfer from an existing online member), it automatically switches over to a new donor, and retries the state transfer. The number of times the joining member retries before giving up is set by the group_replication_recovery_retry_count system variable. The Performance Schema table replication_applier_status_by_worker displays the error that caused the last retry. Previously, this error was only shown if the group member was configured with parallel replication applier threads (as set by the slave_parallel_workers system variable). If the group member was configured with a single applier thread, the error was cleared after each retry by an internal RESET SLAVE operation, so it could not be viewed. This was also the case for the output of the SHOW SLAVE STATUS command whether there were single or multiple applier threads. The RESET SLAVE operation is now no longer carried out after retrying distributed recovery, so the error that caused the last retry can always be viewed.
Replication: A memory leak could occur when a failed replication group member tried to rejoin a minority group and was disallowed from doing so.
Replication: If a replication slave was set up using a CHANGE MASTER TO statement that did not specify the master log file name and master log position, then shut down before START SLAVE was issued, then restarted with the option --relay-log-recovery set, replication did not start. This happened because the receiver thread had not been started before relay log recovery was attempted, so no log rotation event was available in the relay log to provide the master log file name and master log position. In this situation, the slave now skips relay log recovery and logs a warning, then proceeds to start replication.
Replication: When GTIDs are enabled on a replication master and slave, and the slave connects to the master with the MASTER_AUTO_POSITION=1 option set, the master must send the slave all the transactions that the slave has not already received, committed, or both. If any of the transactions that should be sent by the master have been already purged from the master's binary log, the master sends the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS (1789) to the slave, and replication does not start.
The message provided for the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS has been changed to provide advice on the correct action in this situation, which is for the slave to replicate the missing transactions from another source, or for the slave to be replaced by a new slave created from a more recent backup. The message advises that the master's binary log expiration period can be revised to avoid the situation in future. In addition, the master now identifies the GTIDs of the purged transactions and supplies them in its error log in the warning message ER_FOUND_MISSING_GTIDS (11809), so that you do not need to calculate the missing GTIDs manually.
macOS: On macOS, configuring MySQL with -DWITH_SSL=system caused mysql_config output to incorrectly include internal CMake names for the static SSL libraries.
There could be a mismatch between the version of OpenSSL used to build the server and the version used for other parts of MySQL such as libraries or plugins. This could cause certain features not to work, such as the LDAP authentication plugins. Now the same version of OpenSSL is used for building everything.
Docker packages were missing the LDAP authentication plugins.
The original table name for a field in a derived table was not always displayed correctly.
MySQL Installer was unable to uninstall MySQL 5.7 on Windows Server 2012.
With multiple sessions executing concurrent INSERT ... ON DUPLICATE KEY UPDATE statements into a table with an AUTO_INCREMENT column but not specifying the AUTO_INCREMENT value, inserts could fail with a unique index violation.
With lower_case_table_names=2, SHOW TABLES could fail to display tables with uppercase names.
With keyring_encrypted_file_password set on the command line at server startup, the password value could be visible to system utilities.
With a LOCK TABLES statement in effect, a metadata change for the locked table could cause Performance Schema or SHOW queries for session variables to hang in the opening_tables state.
A SELECT using a WHERE condition of the form A AND (B OR C [OR ...]) resulting in an impossible range led to an unplanned exit of the server.
For JSON-format audit logging, the id field now may contain values larger than 65535. Previously, with heaving logging activity, more than 65536 queries per second could be executed, exceeding the 16 bits permitted for id values.
An incomplete connection packet could cause clients not to properly initialize the authentication plugin name.
Client programs that used the libmysqlclient C client library could exit upon receipt of an OK packet containing malformed session-tracking information.
Under certain conditions, enabling the read_only or super_read_only system variable did not block concurrent DDL statements executed by users without the SUPER privilege.
mysqlpump exits rather than dumping databases that contain an invalid view, by design, but it also failed if an invalid view existed but was not in any of the databases to be dumped.
|
