MySQL Community Server 8.0.18 has been released, part 1/2
Posted by: Bjørn Munch
Date: October 14, 2019 07:37AM
Date: October 14, 2019 07:37AM
[Due to size limitations, this announcement is split in two. This is part 1]
Dear MySQL users,
MySQL Server 8.0.18, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.18 is
recommended for use on production systems.
For an overview of what's new in MySQL 8.0, please see
http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html
For information on installing MySQL 8.0.18 on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/8.0/en/installing.html
MySQL Server 8.0.18 is available in source and binary form for a number of
platforms from our download pages at
http://dev.mysql.com/downloads/mysql/
MySQL Server 8.0.18 is also available from our repository for Linux
platforms, go here for details:
http://dev.mysql.com/downloads/repo/
Windows packages are available via the Installer for Windows:
http://dev.mysql.com/downloads/installer/
along with .ZIP (no-install) packages for more advanced needs.
8.0.18 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.:
http://bugs.mysql.com/report.php
The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.17. It may also be viewed
online at
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html
Enjoy!
Edited 1 time(s). Last edit at 10/14/2019 07:46AM by Bjørn Munch.
Dear MySQL users,
MySQL Server 8.0.18, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.18 is
recommended for use on production systems.
For an overview of what's new in MySQL 8.0, please see
http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html
For information on installing MySQL 8.0.18 on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/8.0/en/installing.html
MySQL Server 8.0.18 is available in source and binary form for a number of
platforms from our download pages at
http://dev.mysql.com/downloads/mysql/
MySQL Server 8.0.18 is also available from our repository for Linux
platforms, go here for details:
http://dev.mysql.com/downloads/repo/
Windows packages are available via the Installer for Windows:
http://dev.mysql.com/downloads/installer/
along with .ZIP (no-install) packages for more advanced needs.
8.0.18 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.:
http://bugs.mysql.com/report.php
The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.17. It may also be viewed
online at
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html
Enjoy!
Changes in MySQL 8.0.18 (2019-10-14) * Account Management Notes * Compilation Notes * Configuration Notes * Connection Control Notes * Deprecation and Removal Notes * Keyring Notes * Logging Notes * Optimizer Notes * Packaging Notes * Pluggable Authentication * Spatial Data Support * sys Schema Notes * Test Suite Notes * X Plugin Notes * Functionality Added or Changed * Bugs Fixed Account Management Notes * The CREATE USER, ALTER USER, and SET PASSWORD statements now have the capability of generating random passwords for user accounts, as an alternative to requiring explicit administrator-specified literal passwords. See Random Password Generation (https://dev.mysql.com/doc/refman/8.0/en/password-management.html#random-password-generation). Compilation Notes * Incompatible Change: The my_ulonglong type is no longer used in MySQL source code. Any third-party code that used this type should use the uint64_t C type instead. Also, it is possible that printf() format strings will need adjustment if used to print my_ulonglong variables. (Bug #29453827) * The minimum version of the Boost library for server builds is now 1.70.0. (Bug #29639344) * A DBUG_TRACE macro is available to assist in writing debug code. It is a convenience that replaces pairs of enter/leave macros. For example, instead of writing this: void foo() { DBUG_ENTER("foo"); bar(); DBUG_VOID_RETURN; } Write this instead: void foo() { DBUG_TRACE; bar(); } (Bug #29589102) Configuration Notes * CMake now enables use of fastcov if it is available. fastcov is faster than lcov or gcov. This requires GCC and gcov versions of 9 or higher. (Bug #30011512) * The DISABLE_SHARED CMake option was unused and has been removed. (Bug #29971049, Bug #96027) * The CMake code to find Protobuf executables now works on platforms that split these into multiple packages. (Bug #29953773) * The new ADD_GDB_INDEX CMake option determines whether to enable generation of a .gdb_index section in binaries, which makes loading them in a debugger faster. The option is disabled by default. It has no effect if a linker other than lld or GNU gold is used. (Bug #29925009, Bug #95857) * For the INSTALL_LAYOUT CMake option, the SLES and WIN option values were not used and have been removed. (Bug #29871520, Bug #95654) * The max_prepared_stmt_count system variable maximum value has been increased from 1 million (1,048,576) to 4 million (4,194,304). The default value remains unchanged at 16,382. * MySQL 8.0 no longer supports building using wolfSSL. All MySQL builds now use OpenSSL. * The RE2 library is no longer used by MySQL. The library is no longer bundled with source distributions and the WITH_RE2 CMake option is obsolete. Connection Control Notes * MySQL now provides more control over the use of compression to minimize the number of bytes sent over connections to the server. Previously, a given connection was either uncompressed or used the zlib compression algorithm. Now, it is also possible to use the zstd algorithm (zstd 1.3), and to select a compression level for zstd connections. The permitted compression algorithms can be configured on the server side, as well as on the connection-origination side for connections by client programs and by servers participating in master/slave replication or Group Replication. For more information, see Connection Compression Control (https://dev.mysql.com/doc/refman/8.0/en/connection-compression-control.html). Connection compression using the zstd algorithm requires that the server be built with zstd library support. The new WITH_ZSTD CMake option indicates whether to use the bundled or system zstd library. Legacy compression-control parameters, such as the --compress client option, are deprecated and will be removed in a future MySQL version. Thanks to Facebook for a contribution on which some of this work was based. Deprecation and Removal Notes * Use of the MYSQL_PWD environment variable to specify a MySQL password is considered insecure because its value may be visible to other system users. MYSQL_PWD is now deprecated and support for it will be removed in a future MySQL version. Keyring Notes * MySQL Enterprise Edition now includes a keyring_hashicorp plugin that uses HashiCorp Vault as a back end for keyring storage. For more information, see The MySQL Keyring (https://dev.mysql.com/doc/refman/8.0/en/keyring.html). Logging Notes * Log buffering during server startup was adjusted for less delay in the appearance of output in the error log. (Bug #30019632) Optimizer Notes * Queries involving first match split jump operations were handled wrongly in the iterator executor. They are now rewritten to weedout. (Bug #30220791) * Hash joins have been implemented as a way of executing inner equi-joins in MySQL. For example, a query such as this one can be executed as a hash join beginning with this release: SELECT * FROM t1 JOIN t2 ON t1.c1 = t2.c1; Multi-table joins using equi-joins can also take advantage of this optimization. A hash join requires no index for execution. In most cases, a hash join is more efficient than the block-nested loop algorithm previously used for equi-joins without indexes. By default, beginning with this release, a hash join is used whenever a join includes at least one equi-join condition. This preference can be overridden by setting the hash_join optimizer switch to off, or by using the NO_HASH_JOIN optimizer hint. In addition, you can control the amount of memory used by a hash join by setting join_buffer_size. A join whose memory requirement exceeds this amount is executed on disk; an on-disk hash join uses a number of disk files and may not be executable if this number exceeds open_files_limit. A hash join cannot be employed if the join conditions for any pair of joined tables do not include at least one equi-join condition among all join conditions used. A hash join is used for a Cartesian product---that is, a join that specifies no join conditions at all. You can see whether hash joins have been used to optimize a query in the output of EXPLAIN FORMAT=TREE or EXPLAIN ANALYZE. For more information, see Hash Join Optimization (https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html). * Added EXPLAIN ANALYZE, which provides iterator-based timing, cost, and other information about queries in TREE format. This statement produces output similar to that of EXPLAIN, but with additional information about how optimizer estimates match actual execution. * MySQL now performs injection of casts into queries to avoid certain data type mismatches; that is, the optimizer now adds casting operations in the item tree inside expressions and conditions in which the data type of the argument and the expected data type do not match. This makes the query as executed equivalent to one which is compliant with the SQL standard while maintaining backwards compatibility with previous releases of MySQL. Such implicit casts are now performed between temporal types and numeric types by casting both arguments as DOUBLE whenever they are compared using any of the standard numeric comparison operators. They are also now performed for such comparisons between DATE or TIME values and DATETIME values, in which case the arguments are cast as DATETIME. For example, a query such as SELECT * FROM t1 JOIN t2 ON t1.int_col = t2.date_col is rewritten and executed as SELECT * FROM t1 JOIN t2 ON CAST(t1.int_col AS DOUBLE) = CAST(t2.date_col AS DOUBLE), and SELECT * FROM t1 JOIN t2 ON t1.time_col = t2.date_col is transformed to SELECT * FROM t1 JOIN t2 ON CAST(t1.time_col AS DATETIME) = CAST(t2.date_col AS DATETIME) prior to execution. It is possible to see when casts are injected into a given query by viewing the output of EXPLAIN ANALYZE, EXPLAIN FORMAT=JSON, or EXPLAIN FORMAT=TREE. EXPLAIN can also be used, but in this case it is also necessary to issue SHOW WARNINGS afterwards. This change is not expected to cause any difference in query results or performance. Packaging Notes * The component_test_page_track_component.so test plugin has been moved to -test packages. (Bug #30199634) * Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.65.3. (Bug #30015512) Pluggable Authentication * To assist in debugging failed connections for accounts that use an LDAP authentication plugin, the authentication_ldap_simple_log_status and authentication_ldap_sasl_log_status system variables now accept a maximum value of 6 (formerly 5). Setting either variable to 6 causes debugging messages from the LDAP library to be written to the error log for the corresponding plugin. (Bug #29771393) Spatial Data Support * Previously, for geometry arguments in a geographic (ellipsoidal) SRS, ST_Distance() supported only argument types of Point and Point, or Point and MultiPoint. ST_Distance() now supports distance calculations for geographic SRS arguments of all geometry types. For more information, see Spatial Relation Functions That Use Object Shapes (https://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-object-shapes.html). sys Schema Notes * The sys.schema_unused_indexes view now filters out unique indexes. Thanks to Gillian Gunson for the contribution. (Bug #24798995, Bug #83257) * The sys.ps_is_consumer_enabled() function now produces an error rather than returning NULL if the argument is an unknown non-NULL consumer name. (Bug #24760317) * Previously, sys schema sources were maintained in a separate Git repository. sys schema sources now are included with and maintained within MySQL source distributions (under scripts/sys_schema). As a consequence of this change, to simplify maintenance of sys schema scripts going forward, the acceptable format of statements in the file named by the init_file system variable has been expanded. For details, see the description of that variable in Server System Variables (https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html). The sys.version view is deprecated and will be removed in a future MySQL version. Affected applications should be adjusted to use an alternative instead. For example, use the VERSION() function to retrieve the MySQL server version. Test Suite Notes * MySQL tests were updated to use the latest version of googletest. (Bug #30079649) X Plugin Notes * X Protocol did not correctly display large numbers of warning messages that were issued for the same query. (Bug #30055869) * When the NO_BACKSLASH_ESCAPES SQL mode was enabled, X Plugin incorrectly reported collections as tables. (Bug #28208285) Functionality Added or Changed * When the server is run with --initialize, there is no reason to load non-early plugins. The server now logs a warning and ignores any --plugin-load or --plugin-load-add options given with --initialize. (Bug #29622406) * The number of diagnostic messages relating to INFORMATION_SCHEMA upgrade during server startup has been reduced. (Bug #29440725, Bug #94559) * Prior to MySQL 8.0, REVOKE produced an error for attempts to revoke an unknown privilege. In MySQL 8.0, an account can possess a privilege that is currently unknown to the server if it is a dynamic account that was granted while the component or plugin that registers the privilege was installed. If that component or plugin is subsequently uninstalled, the privilege becomes unregistered, although accounts that possess the privilege still possess it. Revoking such a privilege cannot be distinguished from revoking a privilege that actually is invalid, so REVOKE no longer produces an error for attempts to revoke an unknown privilege. However, to indicate that the privilege is currently unknown, REVOKE now produces a warning. (Bug #29395197) * The new innodb_idle_flush_pct variable permits placing a limit on page flushing during idle periods, which can help extend the life of solid state storage devices. See Limiting Buffer Flushing During Idle Periods (https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool-flushing.html#innodb-limit-flushing-rate). Thanks to Facebook for the contribution. (Bug #27147088, Bug #88566) * mysqld invoked with the --help option no longer aborts if the secure_file_priv argument does not exist. (Bug #26336130) * For group communication connections, Group Replication now supports the TLSv1.3 protocol, which was supported by MySQL Server from 8.0.16. To use the TLSv1.3 protocol, MySQL Server must be compiled using OpenSSL 1.1.1 or higher. For information on configuring encrypted connections for Group Replication, see Group Replication Secure Socket Layer (SSL) Support (https://dev.mysql.com/doc/refman/8.0/en/group-replication-secure-socket-layer-support-ssl.html). * A new option OFFLINE_MODE is available for the group_replication_exit_state_action system variable, which specifies how Group Replication behaves when a server instance leaves the group unintentionally, for example after encountering an applier error, or in the case of a loss of majority, or when another member of the group expels it due to a suspicion timing out. When OFFLINE_MODE is specified as the exit action, Group Replication switches MySQL to offline mode by setting the system variable offline_mode to ON. When the member is in offline mode, connected client users are disconnected on their next request and connections are no longer accepted, with the exception of client users that have the CONNECTION_ADMIN or SUPER privilege. Group Replication also sets the system variable super_read_only to ON, so clients cannot make any updates, even if they have connected with the SUPER privilege. The OFFLINE_MODE exit action prevents updates like the default READ_ONLY exit action does, but also prevents stale reads (with the exception of reads by client users with the stated privileges), and enables proxy tools such as MySQL Router to recognize that the server is unavailable and redirect client connections. It also leaves the instance running so that an administrator can attempt to resolve the issue without shutting down MySQL, unlike the existing alternative ABORT_SERVER exit action, which shuts down the instance. * By default, MySQL replication (including Group Replication) does not carry out privilege checks when transactions that were already accepted by another server are applied on a replication slave or group member. From MySQL 8.0.18, you can create a user account with the appropriate privileges to apply the transactions that are normally replicated on a channel, and specify this as the PRIVILEGE_CHECKS_USER account for the replication applier. MySQL then checks each transaction against the user account's privileges to verify that you have authorized the operation for that channel. The account can also be safely used by an administrator to apply or reapply transactions from mysqlbinlog output, for example to recover from a replication error on the channel. The use of a PRIVILEGE_CHECKS_USER account helps secure a replication channel against the unauthorized or accidental use of privileged or unwanted operations. You grant the REPLICATION_APPLIER privilege to enable a user account to appear as the PRIVILEGE_CHECKS_USER for a replication applier thread, and to execute the internal-use BINLOG statements used by mysqlbinlog. After setting up the user account, use the GRANT statement to grant additional privileges to enable the user account to make the database changes that you expect the applier thread to carry out, such as updating specific tables held on the server. These same privileges enable an administrator to use the account if they need to execute any of those transactions manually on the replication channel. If an unexpected operation is attempted for which you did not grant the appropriate privileges, the operation is disallowed and the replication applier thread stops with an error. * An internal message service has been added to Group Replication. MySQL modules can use the service to transmit generic messages with an identifying tag to all group members, using Group Replication's existing group communication connections. * The relay_log_info_file system variable and --master-info-file option are now deprecated. These were used to specify the name of the relay log info log and master info log when --relay-log-info-repository=FILE and --master-info-repository=FILE were set, but those settings have been deprecated. The use of files for the relay log info log and master info log has been superseded by crash-safe slave tables, which are the default in MySQL 8.0. * The --slave-rows-search-algorithms option and the slave_rows_search_algorithms system variable are now deprecated. These were used to control how rows were searched for matches when preparing batches of rows for row-based logging and replication. The default setting INDEX_SCAN,HASH_SCAN has been found to be optimal for performance and works correctly in all scenarios. * The log_bin_use_v1_row_events system variable is now deprecated. When set to ON, the variable made mysqld write the binary log using Version 1 binary log row events, instead of Version 2 binary log row events which are the default from MySQL 5.6. (The default is OFF.) The use of Version 1 binary log row events enabled row-based replication with slaves running MySQL Server 5.5 and earlier, which could not use Version 2 binary log row events. * The WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() function is now deprecated, and the WAIT_FOR_EXECUTED_GTID_SET() function should be used instead. Both functions wait until all of the specified transactions have been applied, or until the optional timeout has elapsed. However, WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() applied to a specific replication channel, and stopped only after the transactions had been applied on that channel, for which the applier had to be running. In contrast, WAIT_FOR_EXECUTED_GTID_SET() stops after the specified transactions have been applied on the server, regardless of how they were applied (on any replication channel or from any user client), and whether or not any replication channels are running. WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() could hang indefinitely if an expected transaction arrived on a different replication channel or from a user client, for example in a failover or manual recovery situation, and no timeout was set. Bugs Fixed * NDB Cluster: A query handled using a pushed condition produced incorrect results when it included an ORDER BY clause. (Bug #29595346) References: This issue is a regression of: Bug #28672214. * NDB Cluster: The NDB transporter layer limits the size of messages to 32768 bytes; send buffers place additional (and stricter) limitations on message size. Whenever a message is appended to a send buffer, page checks are performed to ensure that the message fits in the available space; if not, a new page is used. The current issue arose on account of the fact that no check was performed to make sure that this message could fit in the empty page; when the size of the message exceeded the empty page, this resulted in a buffer overwrite and in the overwriting of the next page in memory. For data nodes the largest message supported by the send buffer (thr_send_page) is 32756 bytes; for API and management nodes, this maximum is 32752 bytes. (Signals sent within an individual data node are not subject to these limitations since no send or transporter buffers are used in this case). Now, when a new page is used, the size of the message is checked against that which is available in a new page. As part of the work done to fix the problem just described, three new DUMP commands are added to facilitate related testing and debugging: DUMP 103003 (CmvmiRelayDumpStateOrd) sends a DUMP command using another node; DUMP 103004 (CmvmiDummySignal) and DUMP 103005 (CmvmiSendDummySignal) can be used to send long messages. (Bug #29024275) * NDB Cluster: EXPLAIN FORMAT=TREE did not provide proper explanations of conditions and joins pushed down to the NDBCLUSTER storage engine. Issues included the following: + Pushed conditions were not shown. + The root of a pushed join was not shown. + The child of a pushed join did not include any reference to its parent operation. * 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. (Bug #30342846) * InnoDB: An DROP UNDO TABLESPACE operation on an undo tablespace with a missing data file caused a segmentation fault. (Bug #30155290) * InnoDB: An error in the internal trx_rseg_add_rollback_segments function was corrected. (Bug #30114226, Bug #96372) * InnoDB: Problematic assertion code in the Contention-Aware Transaction Scheduling (CATS) code was revised. (Bug #30086559) * InnoDB: Arguments passed to a derived class in calls from the ib::fatal and ib::fatal_or_error constructors could be ignored, resulting in invalid error messages. Additionally, in the case of a fatal error, the ib::fatal_or_error destructor could cause a server exit before printing a message. (Bug #30071930) * InnoDB: It was possible for a corrupted table to be removed from the table cache before the reference count for the table reached zero. (Bug #30065947, Bug #96224) * InnoDB: A code path for the internal row_update_inplace_for_intrinsic() function did not include a required mini-transaction (mtr) commit, causing a debug assertion failure. (Bug #30065518) * InnoDB: The internal fsp_srv_undo_tablespace_fixup() function did not take an undo::ddl_mutex lock when called during startup, which could lead to an assertion failure under certain circumstances. (Bug #30029433) * InnoDB: Inspection of rename_tablespace_name() function showed that if old_shard->get_space_by_id(space_id) did not find the tablespace ID, it would return without calling old_shard->mutex_release(). (Bug #30027771) * InnoDB: A tablespace with "FTS" in its name was incorrectly determined to be the tablespace of a full-text index table and not registered with the data dictionary during upgrade, causing the upgrade operation to fail. (Bug #29992589) * InnoDB: The ibuf_merge_or_delete_for_page() function, responsible for merging and deleting pages in the change buffer, is no longer called for undo tablespaces and temporary tablespaces. The change buffer does not contain entries for those tablespace types. (Bug #29960394, Bug #95989) * InnoDB: Some combinations of buffer pool size variables (--innodb-buffer-pool-instances, --innodb-buffer-pool-size, and --innodb-buffer-pool-chunk-size) lead to a chunk size that is 0, 1, or a value that is not a multiple of the page size, and so on, causing errors during buffer pool creation and sizing. (Bug #29951982) * InnoDB: A server exit while an undo tablespace was being truncated caused the following error when a clone operation was rolled forward after restarting the server: [ERROR] [MY-011825] [InnoDB] [FATAL] Clone File Roll Forward: Invalid File State: 0. (Bug #29949917) * InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation caused a hang condition. (Bug #29942556, Bug #30324703) * InnoDB: Cloning operations failed with the following error after an archive thread failure: ERROR 3862 (HY000): Clone Donor Error: 1317 : Query execution was interrupted. (Bug #29930839) * InnoDB: A clone related regression caused a minor drop in performance for index and non-index update operations. (Bug #29925409) * InnoDB: InnoDB now ignores hidden directories and files during the tablespace discovery scan that occurs at startup. Hidden directories and files include those beginning with "." and hidden and system directories and files on Windows that are identified by attributes. (Bug #29900671, Bug #95071, Bug #30068072) * InnoDB: To improve deadlock detection, the task of detecting a deadlock cycle among data locks was moved from the transaction thread to a dedicated background thread. (Bug #29882690) * InnoDB: Updating the mysql.gtid_executed table during mysqld initialization caused the following warning to be printed to the error log: [Warning] [MY-010015] [Repl] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened. The update and associated warning no longer occur. (Bug #29871809) * InnoDB: The LATEST DETECTED DEADLOCK section in InnoDB Standard Monitor output (also printed by SHOW ENGINE INNODB STATUS) was extended to include additional information about transactions that participate in a deadlock cycle. (Bug #29871641) * InnoDB: An incorrect argument was used to compare serialized dictionary information (SDI) input and output values when checking the size of the buffer used to store SDI. (Bug #29871525, Bug #95606) * InnoDB: An undo tablespace file was overwritten during a cloning operation when undo tablespaces files with the same name were copied from different directories on the donor to the same directory on the recipient. A cloning operation now reports an error if duplicate undo tablespace names are encountered. When data is cloned to the recipient, undo tablespace files are cloned to the directory defined by the innodb_undo_directory variable. Because the files are cloned to the same directory, duplicate undo tablespace file names are not permitted. (Bug #29837617) * InnoDB: A cloning operation generated a large number of redo log files when cloning from a MySQL server instance with a small redo log file size and a large number of transactions. The large number of redo log files sometimes caused startup to hang or assert. Otherwise, startup was permitted proceed without cleaning up the excessive number of redo log files. (Bug #29837490) * InnoDB: During recovery, missing table errors that occur when applying redo logs to encrypted tables could be ignored, permitting startup to proceed. Startup should be halted in this case. (Bug #29820184, Bug #95183) * InnoDB: The wrong redo log file size was printed to the server error log at startup. (Bug #29818711) * InnoDB: A restriction that prevented reuse of lock objects (lock_t structs) in the lock queue when waiting record lock requests were present was removed. (Bug #29814308) * InnoDB: When converting a long partitioned table name to a file name, the buffer that holds the file name did not have enough space, causing an assertion failure. (Bug #29813582) * InnoDB: Some transaction lock structure fields (trx->lock) were not properly mutex protected. (Bug #29809137) * InnoDB: An empty undo segment update during recovery raised an assertion. (Bug #29802703) * InnoDB: A cloning operation failed when attempting to drop data on the recipient if the recipient data included a table with a full-text index. (Bug #29796507) * InnoDB: After a file-per-table tablespace was discarded, an error was reported when the old table was renamed and a new table was created with the same name. The error was due to stale file path information. (Bug #29793800) * InnoDB: A test case that attempts to open a file in read-only mode while the server is in a disk-full state caused a debug assertion failure. The assertion was removed to permit the server to retry opening the file, and to report an error if unsuccessful after a number of attempts. (Bug #29692250, Bug #95128) * InnoDB: Foreign-key-related tables constructed during a RENAME TABLE operation contained the old table name. (Bug #29686796) * InnoDB: The server passed a NULL value for a column with a non-zero data length. (Bug #29654465) * InnoDB: Importing a partitioned table from a MySQL 8.0.13 instance (or earlier) to a MySQL 8.0.14, 8.0.15, or 8.0.16 instance failed with a "tablespace is missing" error for source and target instances defined with lower_case_table_names=1. The tablespace file and the metadata file used by the import operation could not be found due to a file name case mismatch. (Bug #29627690, Bug #94850) References: This issue is a regression of: Bug #26925260. * InnoDB: The read set (TABLE::read_set) was not set properly for handler method calls in QUICK_SKIP_SCAN_SELECT::get_next(), causing an assertion failure. (Bug #29602393) * InnoDB: An exclusive backup lock is now used to block tablespace truncate operations during master key rotation. Previously, metadata locks on undo tablespace names were used to synchronize the operations. (Bug #29549938) * InnoDB: An unnecessary next key lock was taken when performing a SELECT...FOR [SHARE|UPDATE] query with a WHERE condition that specifies a range, causing one too many rows to be locked. The most common occurrences of this issue have been addressed so that only rows and gaps that intersect the searched range are locked. (Bug #29508068) * InnoDB: Adding a virtual column in the first position together with a normal column raised an assertion failure. (Bug #29501324) * InnoDB: The shutdown process did not wait for InnoDB background threads to exit, which could cause shutdown to stall, waiting for background threads to remove transactions from the MySQL transaction list. A check now occurs to ensure that InnoDB background threads have exited properly. Also, an intermediate shutdown state was added to improve shutdown timing for the InnoDB master thread. (Bug #29417503) * InnoDB: A memory leak occurred during TempTable storage engine operation due a failure to deallocate that last block of allocated memory, which TempTable holds in thread-local storage until thread exit. (Bug #29300927) * InnoDB: Delete marked rows were able to acquire an external read lock before a partial rollback was completed. The external read lock prevented conversion of an implicit lock to an explicit lock during the partial rollback, causing an assertion failure. (Bug #29195848) * InnoDB: The INFORMATION_SCHEMA.INNODB_COLUMNS table did not display partitioned table columns after upgrading from MySQL 5.7 to MySQL 8.0. For partitioned tables created on the MySQL 8.0 release, INFORMATION_SCHEMA.INNODB_COLUMNS only displayed columns for the first table partition. (Bug #28869903, Bug #93033) * InnoDB: The internal rtr_page_split_and_insert() function is called recursively. An inner call to the function released an object still being used by an outer call to the same function, causing an assertion failure. (Bug #28569379) * InnoDB: Under specific circumstances, setting the innodb_limit_optimistic_insert_debug variable to 2 raised a debug assertion when it should have reported an error. (Bug #28552330, Bug #92187) * InnoDB: A deadlock was possible when a transaction tries to upgrade a record lock to a next key lock. (Bug #23755664, Bug #82127) * InnoDB: An error reported during a read operation did not identify the name of the file that was read. (Bug #21120885, Bug #76020)
Edited 1 time(s). Last edit at 10/14/2019 07:46AM by Bjørn Munch.
Subject
Views
Written By
Posted
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.