MySQL Community Server 8.0.17 has been released (part 2/3)
Posted by: Balasubramanian Kandasamy
Date: July 22, 2019 03:06AM
Date: July 22, 2019 03:06AM
[This is part 2 of the announcement] Bugs Fixed * NDB Cluster: Compile times for NDB Cluster using the included compile_cluster build script have been improved by removing options for software components not strictly necessary for running MySQL Cluster. (Bug #29355872) * NDB Cluster: Attempting to change an NDB table's column properties (such as COLUMN_FORMAT) using ALTER TABLE ALGORITHM=INPLACE was rejected, which is correct behavior, but which raised a misleading error message. (Bug #28929906) * InnoDB: A failure occurred when attempting to kill a process that was executing a row count. (Bug #29939617) * InnoDB: Due to a regression introduced in MySQL 8.0.14, in-place upgrade on a case sensitive file system from MySQL 5.7 or a MySQL 8.0 release prior to MySQL 8.0.14 to MySQL 8.0.16 failed for instances with partitioned tables and lower_case_table_names=1. The failure was caused by a case mismatch issue related to partitioned table file names. The fix that introduced the regression was reverted, which permits upgrades to MySQL 8.0.17 from MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to function as normal. However, the regression is still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases. In-place upgrade on a case sensitive file system from MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 fails with the following error when starting the server after upgrading binaries or packages to MySQL 8.0.17 if partitioned tables are present and lower_case_table_names=1: Upgrading from server version version_number with partitioned tables and lower_case_table_names == 1 on a case sensitive file system may cause issues, and is therefore prohibited. To upgrade anywa y, restart the new server version with the command line option 'upgrade=F ORCE'. When upgrade is completed, please execute 'RENAME TABLE part_table_nam e TO new_table_name; RENAME TABLE new_table_name TO part_table_name;' for each of the partitioned tables. Please see the documentation for further information. If you encounter this error when upgrading to MySQL 8.0.17, perform the following workaround: 1. Restart the server with --upgrade=FORCE to force the upgrade operation to proceed. 2. Identify partitioned table file names with lowercase suffixes: mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%'; 3. For each file identified, rename the associated table using a temporary name, then rename the table back to its original name. mysql> RENAME TABLE table_name TO temporary_table_name; mysql> RENAME TABLE temporary_table_name TO table_name; 4. Verify that there are no partitioned table file names with lowercase suffixes (an empty result set should be returned). mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%'; Empty set (0.00 sec) 5. Run ANALYZE TABLE on each renamed table to update the optimizer statistics in the mysql.innodb_index_stats and mysql.innodb_table_stats tables. Because of the regression still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases, importing partitioned tables from MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 is not supported on case sensitive file systems where lower_case_table_names=1. Attempting to do so results in a "Tablespace is missing for table" error. (Bug #29823032, Bug #29917793, Bug #95834) References: This issue is a regression of: Bug #26925260. * InnoDB: lock_sys mutex contention caused by lock-wait functions (lock_wait_suspend_thread() and lock_wait_table_release_slot()) was reduced. (Bug #29814339) * InnoDB: The fseg_n_reserved_pages_low() function, which determines the number of pages reserved by a segment, did not validate results read from the segment inode. (Bug #29761998) * InnoDB: Creation of the transaction rollback list (hit_list) was decoupled from lock acquisition calls (lock_rec_lock calls) to permit the use of different latching schemes. (Bug #29753800) * InnoDB: Disabling Performance Schema consumers caused an ALTER TABLESPACE ... ENCRYPTION operation to assert. (Bug #29646974, Bug #95005) * InnoDB: Error messages were revised to remove references to .frm files, which are not used in MySQL 8.0. (Bug #29639655) * InnoDB: It was possible for a background thread to check the encryption status of an undo tablespace before the undo tablespace was fully initialized and the encryption flag set. (Bug #29600309) * InnoDB: A table name parsing function call returned false when parsing serialized dictionary information (SDI) tables names, which are not formatted to include a database name. The buffer that holds the database name remained uninitialized, causing Valgrind errors. (Bug #29550527) * InnoDB: The space reserved in the mini-transaction (mtr) log buffer for dynamic metadata logging was insufficient. (Bug #29524260) * InnoDB: Inaccuracies in the Variance-Aware Transaction Scheduling (VATS) implementation raised a signed integer overflow error in an UBSan build of MySQL. (Bug #29508517, Bug #91959) * InnoDB: Insufficient memory barriers in the rw-lock implementation caused deadlocks on ARM. Thanks to Yibo Cai from Arm Technology for the contribution. (Bug #29508001, Bug #94699) * InnoDB: The INFORMATION_SCHEMA.INNODB_TABLESPACES ENCRYPTION column was not updated after enabling undo tablespace encryption. (Bug #29492911, Bug #94665) * InnoDB: A relocated table could not be accessed due to incorrect parsing of a schema or table name that included a forward slash character (/), which the server incorrectly interpreted as a directory separator. (Bug #29492113) * InnoDB: Various fixes and revisions were applied to the InnoDB memcached source code. (Bug #29485891) * InnoDB: To enable global access, the value of innodb_directories variable is now stored internally as a global variable instead of a static variable. (Bug #29471990) * InnoDB: In debug builds, the thd_innodb_tmpdir() function did not accept a NULL argument. (Bug #29471846) * InnoDB: A subtraction operation in the file space allocation code incorrectly stored the result as an unsigned variable, which raised an assertion failure. (Bug #29466680) * InnoDB: After moving or deleting default undo tablespaces and restarting the server with a new innodb_undo_directory value, MySQL recreated the undo tablespaces in the new location but failed to update the undo directory path in the data dictionary. (Bug #29461900) * InnoDB: A previously freed LOB page was accessed while rolling back a transaction during recovery. (Bug #29440408) * InnoDB: A request was issued during recovery to read pages into the buffer pool when there were no pages to be read. A check was added to avoid the unnecessary read request. (Bug #29440208) * InnoDB: A regression introduced in MySQL 8.0.14 caused a "Invalid (old?) table or database name" error when creating a partitioned table on a MySQL instance with lower_case_table_names=1. The change that caused the regression has been reverted. (Bug #29426720, Bug #94519) References: This issue is a regression of: Bug #26925260. * InnoDB: A FULLTEXT index table created in MySQL 5.6 in a database with a hyphen in its name caused a startup failure after upgrading from MySQL 5.7 to MySQL 8.0. Tablespace file paths for FULLTEXT auxiliary tables were not found in the data dictionary, and the hyphen in the database name was not handled correctly in subsequently generated file paths. (Bug #29411899, Bug #94431) * InnoDB: There was potential for data loss to occur if the redo log was not logically empty and comprised a single block, and the server exited during recovery after an insert buffer merge generated new redo records but before the new records could be flushed to disk. (Bug #29411832, Bug #94448) * InnoDB: InnoDB returned an unknown generic error when attempting to create a tablespace for which the path and file name exceeded the MAX_PATH limit on Windows. InnoDB now returns a more meaningful error. (Bug #29341634) * InnoDB: An undo tablespace file was not found after being moved to a different directory. (Bug #29328158) * InnoDB: The server failed to start with an innodb_buffer_pool_size=default setting. The default value was not checked for compatibility with dependent system variable settings. (Bug #29267814, Bug #94065) * InnoDB: The CREATE TABLESPACE ... ADD DATAFILE clause no longer permits circular directory references. For example, the circular directory reference (/../) in the following statement is not permitted: CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd'; An exception to this restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. For example, the data file path in the example above is permitted if any_directory is a symbolic link. (It is still permitted for data file paths to begin with '../'.) To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading to MySQL 8.0.17 or higher. To inspect tablespace paths, query the INFORMATION_SCHEMA.INNODB_DATAFILES table. (Bug #29157265) * InnoDB: Manually changing the system time while the MySQL server was running caused page cleaner thread delays. (Bug #29138644, Bug #93708) * InnoDB: UPDATE statements did not always disable semi-consistent reads properly when encountering errors, which could lead to assertion errors in debug mode. (Bug #29047894) * InnoDB: When purging a deleted row, the logic that governs lock inheritance did not correctly determine the type of lock that should be inherited to satisfy constraint checks by active transactions. (Bug #29004362) * InnoDB: An unnecessary read lock was taken on implicitly opened data dictionary tables when executing a prepared statement in LOCK TABLES mode. (Bug #28875646) * InnoDB: During log application, after an OPTIMIZE TABLE operation, InnoDB did not populate virtual columns before checking for virtual column index updates. (Bug #28834208) * InnoDB: An operation that copied data from the clustered index was performed incorrectly, causing spatial indexes to use spatial rows with stale pointers to the clustered index. (Bug #28758961) * InnoDB: An INSERT operation involving a generated virtual BLOB column resulted a secondary index being updated with an incorrect value. (Bug #28652826) * InnoDB: Configuring innodb_data_file_path and innodb_temp_data_file_path using SET PERSIST_ONLY = default incorrectly set the variable values to NULL. (Bug #28590014) * InnoDB: A CREATE TABLE ... REPLACE SELECT operation raised a lock_rec_get_rec_not_gap(lock) assertion failure. The operation set a flag on the transaction object indicating that a REPLACE operation was requested, but did not clear the flag before updating dependent views, causing a subsequent INSERT operation to be interpreted as a REPLACE operation, leading to the wrong row locks being taken. (Bug #28523025, Bug #92068) * InnoDB: With super_read_only enabled, an attempted RENAME TABLE operation on a temporary table raised an assertion instead of returning an error. (Bug #28490368, Bug #91975) * InnoDB: Valgrind errors were reported due to uninitialized bytes read during a virtual index prefix search. (Bug #28184025) * InnoDB: InnoDB initialization failed when attempting to create an system tablespace greater than 2GB in size. (Bug #27538464) * 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. (Bug #25289359) * InnoDB: The INNODB_METRICS metadata_table_reference_count counter reported a negative value. (Bug #20584149, Bug #75966) * InnoDB: Client sessions using different auto_increment_increment values while performing concurrent insert operations could cause a duplicate key error. (Bug #15851528, Bug #67526) References: Reverted patches: Bug #14049391, Bug #65225. * Partitioning: For partitioned tables, an ALTER TABLE statement could cause incorrect query results under these conditions: + The statement swapped columns by renaming them, either directly with RENAME COLUMN or by replacement with DROP COLUMN/ADD COLUMN. + A swapped column was used in a partitioning expression. + The alteration was performed as an in-place operation that did not redistribute rows between partitions. Such column renames are now prohibited unless the same ALTER TABLE statement satisfies one of these conditions: + The statement makes the table nonpartitioned. + The statement redefines the table partitioning or partitioning expression (which causes a table rebuild that redistributes rows). This enables supporting existing scenarios in which partitioning expressions are updated to follow column renaming. + Partitioning is specified using PARTITION BY KEY() with an empty column list. This partitions using the primary key, which tracks column renaming. (Bug #29541665, Bug #94792) * 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. (Bug #28687608) * Replication: When message fragmentation is in use for large Group Replication messages (which is available, and the default, from MySQL 8.0.16), if a fragmented message sent by the group member with the highest node identifier in XCom was partially delivered, and one or more members then left the group prior to the delivery of the remaining message fragments, reassembly of the message caused Group Replication to stop working. The loss of members meant that the node identifier of the original sender was no longer valid in the new view of the group. To correct this issue, reassembly of fragmented messages now uses the delivery information from the last fragment that was delivered, which reflects the new situation after the view change, rather than from the first fragment that was delivered, which reflects the old situation before the view change. (Bug #29716639) * 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. (Bug #29542425) * Replication: Group Replication cannot be started following a MySQL Server upgrade that uses the MINIMAL option (--upgrade=MINIMAL), which does not upgrade system tables on which the replication internals depend. Previously, in this situation, the server was waiting indefinitely for Group Replication to start. The situation is now handled correctly by unblocking the waiting thread and issuing the expected error ER_GRP_RPL_START_GRP_RPL_FAILED. (Bug #29423358) * Replication: In Group Replication's Group Communication System (GCS), a change to the processing of suspicions by a member that is leaving the group, which reduced the execution time for some test cases, caused an issue in the event that recovery failed, because it led to a circular dependency between the recovery failure and the view change notification. Now, if an error makes recovery impossible, GCS takes the handling actions in an appropriate sequence. The member leaves the group, the view change is applied, and then the recovery thread is terminated. (Bug #29417365, Bug #29628909) * 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. (Bug #29417234) * 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. (Bug #29390946) * Replication: If a LOCK INSTANCE FOR BACKUP statement was used to acquire an instance-level backup lock, then a STOP SLAVE statement was issued, a deadlock could be created with the SQL thread waiting on the backup lock and the STOP SLAVE statement waiting on the SQL thread to complete its current action. To prevent this situation, the STOP SLAVE process now tries to acquire the backup lock before proceeding, and returns an error if the lock cannot be acquired. (Bug #29386503, Bug #93649) * Replication: From MySQL 8.0.13, if any replication channel has open temporary tables, the binary logging format cannot be changed using SET @@global.binlog_format or SET @@persist.binlog_format. Previously, if this operation was attempted after the new restriction was implemented, the wrong error message was returned to the client (referencing a running replication channel applier as the issue, rather than an open temporary table). The appropriate error message is now returned. (Bug #29370024, Bug #94340) * Replication: Binary log checksums were handled incorrectly when de-serializing a format description event. (Bug #29355110) * Replication: With row-based replication in use, when the replication applier thread unpacked a row change event, index values for any functional indexes were calculated for both the "before" image and the "after" image. In the case of the "before" image, the values were not necessary. This calculation has therefore been removed for the before image in order to optimize row unpacking. (Bug #29304076) * 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. (Bug #29157796, Bug #93771) * Replication: If an invalid starting offset was provided in a SHOW BINLOG EVENTS FROM statement, the invalid offset was returned in place of the correct starting position for the first returned event. (Bug #29039732, Bug #93544) * Replication: The Group Replication UDFs for configuring an online group sometimes did not return an error if an issue arose during main execution. The UDFs also now check whether the Group Replication plugin is stopping before they start to initialize. (Bug #28978767) * Replication: Replication could stop with a "record not found" error when the value INDEX_SCAN,HASH_SCAN (the default in MySQL 8.0) was set for the slave_rows_search_algorithms system variable, and an update event contained two updates to the same row in a table that did not have a unique key, meaning that the hash scan was used. In this situation, the second update was missed by the hash scan due to the row change. Now, after updating a row, the hash scan operation searches for the updated row in the hash map, and applies any further update. When the value TABLE_SCAN,HASH_SCAN is set for the slave_rows_search_algorithms system variable, so that the search cannot use an index, the "record not found" error can occur in the above situation whether or not the table has a unique key. Also, with this setting, when a hash scan is used on a table that has a unique key, in the case of an update event containing two row updates that are order-dependent, the updates might be applied out of order, causing replication to stop with a duplicate key error. To avoid these issues, the documentation has been updated to state that the value TABLE_SCAN,HASH_SCAN should not be used. (Bug #28846386) * Replication: When binary logging is enabled on a replication slave, the combination of the --replicate-same-server-id and --log-slave-updates options on the slave can cause infinite loops in replication if the server is part of a circular replication topology. (In MySQL 8.0, binary logging is enabled by default, and slave update logging is the default when binary logging is enabled.) However, the use of global transaction identifiers (GTIDs) prevents this situation by skipping the execution of transactions that have already been applied. The restriction on this combination of options has therefore now been removed when gtid_mode=ON is set. With any other GTID mode, the server still does not start with this combination of options. As a safeguard against creating the problem situation after the server has started, you now cannot change the GTID mode to anything other than ON on a running server that has this combination of options set. Thanks to Facebook for the contribution. (Bug #28782370, Bug #92754) * 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. (Bug #28702320) * 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. (Bug #28642318, Bug #92398) * Replication: When a trigger invoked an INSERT or UPDATE statement that set a column to its default value, and the DEFAULT expression of that column was non-deterministic, the expected warning was not raised when the trigger fired under statement-based replication. In addition, if the binary logging format was MIXED, the non-deterministic statements were logged in the format used for STATEMENT rather than that used for ROW. The statement that causes the trigger to fire checks at resolution time whether any of the triggered statements are non-deterministic. At this time, the triggered statements have been parsed, but not resolved, so the only check that can be performed is whether the triggered statements directly reference any non-deterministic operators. When the non-deterministic operator is used by a DEFAULT expression, the non-determinism is not visible until the triggered statement has been resolved, which happens when the trigger fires. This is fixed by adding an extra check when determining the logging format, where a statement is flagged as unsafe if any of its substatements can write to a table that has a column with a non-deterministic DEFAULT expression. Since it is not yet known at this point whether the DEFAULT expression will be used by the substatement, this check flags the statement as unsafe even if the substatement provides an explicit value for the column with a non-deterministic DEFAULT expression. (Bug #28297486) * 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. (Bug #27675107, Bug #89987) * Replication: If a replication slave tried to connect to the master using an incorrect user name, host, or port, the original error message specifying the reason for the connection failure was overwritten with a generic message. The issue has now been corrected in the output from the SHOW SLAVE STATUS statement and in the Performance Schema table replication_connection_status. (Bug #26580064) * macOS: For macOS installations performed using DMG packages, launchd operation was problematic: + Previously, SHUTDOWN caused a restart if MySQL was configured to start at boot time via the preference pane. This also affected the mysqladmin shutdown command. Server shutdown initiated in these ways now works correctly. + Previously, RESTART did not work. It now works correctly. + Previously, unexpected server exits did not cause automatic restart if the server was not configured to start at boot time. Exits with a nonzero exit status now cause a restart regardless of boot-time startup configuration. (Bug #29789857) * JSON: MAX() and MIN() used on expressions returning JSON data sometimes compared these values as strings rather than JSON values, which caused unexpected results; this was particularly evident when the JSON values were numbers. This was due to the fact that GROUP BY when using temporary tables with indexes did not compare JSON values correctly. (Bug #28947381) * JSON: JSON_TABLE() returned the error Unknown database '' when executed from a stored function. The root cause of this issue was that, when merging tables from a select that used JSON_TABLE(), MySQL checked only for derived tables. This caused the result table returned by JSON_TABLE() to be noted as a regular table, so that when attempting to execute the query, the server failed to open it. Now MySQL checks whether the table to be added is not an internal table, that is, not a derived table, a JSON_TABLE() result table, or a reference to a recursive common table expression. (Bug #92976, Bug #28851656) * Some foreign key error messages could differ depending on whether the user had the GRANT OPTION privilege. (Bug #29868844) * During upgrade operations, upgrades of the help tables failed if autocommit was disabled. (Bug #29865428, Bug #95620) * Fetching dynamically allocated dictionary objects into a vector during upgrade while operating with a small table_open_cache size caused data dictionary tables to be reopened, triggering a garbage collection mechanism that incorrectly freed collected objects. Subsequent attempts to access the freed objects caused a segmentation fault. (Bug #29823053) * For upgrades from MySQL 5.7 to 8.0, the upgrade process did not close the innodb_*_stats_backup57.ibd files in the mysql system schema before removing them, resulting in errors for subsequent file system operations. (Bug #29791350) * mysqld --initialize would fail if the file system was mounted at the data directory mount point and a lost+found file or directory was present. The lost+found file or directory is now ignored during data directory initialization. (Bug #29780434) * MySQL upgrades did not assign the AUDIT_ADMIN privilege to accounts that had the SUPER privilege. (Bug #29770732) * The REGEXP_REPLACE() function did not handle empty strings correctly in all cases. (Bug #29763554) * An overly strict assertion could be raised during sorting of stored program local objects. (Bug #29759547, Bug #95062) * The group_replication_get_communication_protocol() UDF, which is used to query the group's communication protocol version, failed if any group members were in RECOVERING state, which was an unnecessary restriction. The UDF can now be used provided that the member where it runs is in ONLINE state, and is in contact with a majority of the group. (Bug #29754967) * For some arguments to REPEAT(), maximum length calculations were not always handled correctly. (Bug #29739778) * UPDATE statements for tables with CHECK constraints could fail to enforce the constraints. (Bug #29706621, Bug #95189) * For installation from RPM or Debian packages, if the mysql_upgrade_info file in the data directory is found to exist but is owned by root, it is now changed to the same owner as the data directory. The correct SELinux file context is also set. (Bug #29704041) * Installing from RPM packages could result in an error log with incorrect permissions. (Bug #29702462) * A mysql_upgrade_info file created by the mysql_upgrade program during a previous upgrade could only be modified the operating system user that executed the mysql_upgrade program, causing an upgrade error. A warning is now issued instead of an error, which permits the upgrade operation to proceed. The mysql_upgrade_info file is deprecated and will be removed in a future MySQL version. (Bug #29702060, Bug #95165) * A replication group member that was unable to contact a majority of the group before the group_replication_unreachable_majority_timeout setting was reached, and then exhausted the number of auto-rejoin attempts specified by the group_replication_autorejoin_tries system variable without successfully rejoining, was sometimes unable to carry out the action specified by the group_replication_exit_state_action system variable. The member tries to carry out the action using the current session, which sometimes failed. The member now ensures that the session is initialized before using it to connect to the server to carry out the exit state action. (Bug #29698754) * When performing a upgrade, server-side SQL statements that update data dictionary tables used a non-default collation, causing an upgrade failure. (Bug #29697670, Bug #95144) * Starting the server with --skip-grant-tables and invoking ROLES_GRAPHML() could lead to a server exit. (Bug #29681975) * SELECT DISTINCT when using fixed-length keys did not deduplicate records properly in all cases. (Bug #29628699) * Client programs that used asynchronous C API functions could access freed memory after occurrence of a fatal error such as connection failure or receipt of a too-large packet. (Bug #29596244) * For failed data directory initialization, the server could produce a message indicating that the directory could be removed, even if the server itself did not create it. The message now indicates that only files in the directory created by the server can be removed. (Bug #29594082, Bug #94880) * In MySQL 8.0, the keyring_encypted_file plugin could not read a file created by a MySQL 5.7 keyring_encypted_file plugin. (Bug #29588345) * In builds with Undefined Behavior Sanitizer enabled, runtime errors occurred in my_strtoll10_mb2() and val_decimal(). (Bug #29585648, Bug #29594951) * Some diagnostics produced by the server while checking grant table structure at startup were written as errors rather than warnings. (Bug #29558993) * The comp_err utility could read uninitialized data. (Bug #29550442) * Enabling audit log encryption could cause a server exit. (Bug #29549327) * RPM package obsoletes were updated to enable successful upgrades from MariaDB to MySQL on EL8. (Bug #29549127, Bug #29623146, Bug #29623201, Bug #29659212) * In a join of the form LEFT JOIN t ON column WHERE t.x=0 IS NOT TRUE, MySQL evaluated IS NOT TRUE as FALSE for a NULL argument in a null-complemented row, and rejected it. This caused an invalid conversion of the left join to an inner join, so that there were missing rows in the result. The same issue affected joins of the same form but having IS NOT FALSE in the WHERE condition. (Bug #29540230) * If the read_only system variable was enabled, its value improperly was applied against updates to the character set and collation data dictionary tables. (Bug #29533590, Bug #94769) [To be continued]
MySQL Community Server 8.0.17 has been released (part 2/3)
July 22, 2019 03:06AM
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.