MySQL Forums
Forum List  »  Announcements

MySQL Community Server 8.0.18 has been released, part 1/2
Posted by: Bjørn Munch
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

For information on installing MySQL 8.0.18 on new servers, please see
the MySQL installation documentation at

MySQL Server 8.0.18 is available in source and binary form for a number of
platforms from our download pages at

MySQL Server 8.0.18 is also available from our repository for Linux
platforms, go here for details:

Windows packages are available via the Installer for Windows:

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

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.:

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


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

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

     * 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() {

       Write this instead:
void foo() {

       (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

     * 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

     * 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
       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

Logging Notes

     * Log buffering during server startup was adjusted for less
       delay in the appearance of output in the error log. (Bug

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:
    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
       For more information, see Hash Join Optimization

     * 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,
       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 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

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
       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

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

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

     * 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
       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

     * 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

     * 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

     * 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

     * 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

     * InnoDB: Some combinations of buffer pool size variables
       --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

     * 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

     * InnoDB: Some transaction lock structure fields
       (trx->lock) were not properly mutex protected. (Bug

     * 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

     * 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

     * 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

     * 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)

       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

     * 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

     * 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.

Options: ReplyQuote

Written By
MySQL Community Server 8.0.18 has been released, part 1/2
October 14, 2019 07:37AM

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.