MySQL Forums
Forum List  »  Announcements

MySQL Community Server 8.0.22 has been released (part 2/2)
Posted by: Bjørn Munch
Date: October 19, 2020 08:06AM

[ This is part 2 of the annopuncement]

Bugs Fixed

     * InnoDB: Code related to transaction support for histogram
       sampling was removed, including related assertion code
       that caused test failures. Transaction support is not
       required for histogram sampling. (Bug #31787736)

     * InnoDB: Encryption information was not set for redo log
       archive log writer thread write operations. (Bug

     * InnoDB: The TTASEventMutex::exit function was optimized
       for ARM64.
       Thanks to Krunal Bauskar for the contribution. (Bug
       #31589019, Bug #100132)

     * InnoDB: InnoDB failed to compile with the
       DISABLE_PSI_RWLOCK CMake option enabled. (Bug #31578289)

     * InnoDB: The transaction isolation level, which is set to
       READ UNCOMMITTED for histogram sampling to avoid
       unnecessary lookups of old record versions, was not reset
       after the sampling operation completed. (Bug #31564407)

     * InnoDB: A query that updated the clustered index of an
       internal temporary table returned an incorrect result.
       The modified pages of the clustered index were not added
       to the flush list resulting in lost changes when the
       modified pages were evicted from the buffer pool. (Bug
       References: This issue is a regression of: Bug #29207450.

     * InnoDB: A build dependency on the Boost library defined
       for the TempTable storage engine was removed. (Bug

     * InnoDB: A workaround was implemented to handle a Clang
       compiler issue in 32-bit builds that causes the
       ATOMIC_LLONG_LOCK_FREE value to be defined as "sometimes
       lock-free" while __atomic_always_lock_free returns true
       for the same type on the same platform. (Bug #31504609)

     * InnoDB: A REDUNDANT row format table created in an
       earlier version of MySQL, where the row format was not
       defined explicitly, permitted the addition of an index
       that exceeded the REDUNDANT row format index column size
       limit. (Bug #31479542, Bug #99791)

     * InnoDB: A DML operation on a column defined with a
       multi-valued index caused a failure. (Bug #31479282)

     * InnoDB: A failure occurred during master key rotation. An
       undo tablespace in-memory object was freed prematurely.
       (Bug #31467626)

     * InnoDB: Unused physical read ahead code was removed from
       the parallel read interface. (Bug #31429385)

     * InnoDB: A master key rotation operation failed to skip an
       undo tablespace that was already truncated, which lead to
       an assertion failure when shutting down the server. (Bug

     * InnoDB: After importing a tablespace for a
       page-compressed table, pages were no longer compressed,
       incorrectly indicated that pages were compressed. The
       table's compression information was unavailable during
       the import operation. (Bug #31396947)

     * InnoDB: A rollback and update operation after performing
       an instant DDL operation raised an assertion. (Bug

     * InnoDB: The log system (log_sys) sharded read-write lock
       caused a performance regression in CPU-bound workloads.
       (Bug #31389135)

     * InnoDB: Compiling with the UNIV_ENCRYPT_DEBUG option
       enabled caused compilation errors. (Bug #31369540)

     * InnoDB: DDL operations on a partitioned table could cause
       a failure. TABLE_SHARE and table instance objects were
       opened for all partitions unnecessarily. (Bug #31365127)

     * InnoDB: After changing a VARCHAR column collation from
       utf8mb4 to utf8mb4_bin in an in-place ALTER TABLE
       operation and adding an index on the same column, a
       case-sensitive query on the VARCHAR column returned an
       incorrect result. The VARCHAR column collation was
       changed in the data dictionary but not in the in-memory
       table object. Consequently, the index created on the
       VARCHAR column used stale column information causing
       comparisons to use the previously defined collation. (Bug

     * InnoDB: An ALTER TABLE ... IMPORT TABLESPACE operation on
       a large encrypted and compressed table failed with a Page
       decompress failed after reading from disk error. The
       decryption operation did not use the encryption block
       size used during encryption. Also, the encryption process
       did not consider compressed length, while the decryption
       process decrypts data by compressed length only. (Bug

     * InnoDB: A failure occurred during a concurrent update
       operation. The failure was due to an invalid previous
       record value. (Bug #31205266, Bug #99286)

     * InnoDB: Upgrade from MySQL 5.7 to MySQL 8.0 failed on an
       instance with a table created in a general tablespace and
       defined with a FULLTEXT index. The correct data
       dictionary space ID for table could not determined. (Bug
       #31154128, Bug #99211)

     * InnoDB: The function used to process the SHOW ENGINE
       INNODB MUTEX statement was insufficiently isolated from
       other threads adding new mutexes concurrently. (Bug

     * InnoDB: Failure to call a buffer pool page I/O completion
       routine resulted in orphan buffer pool I/O write pages.
       (Bug #31073853)

     * InnoDB: Numerous system temporary table pages at the tail
       of the buffer pool flush list caused a performance
       degradation. The flush_list_mutex was held while the
       flush list scan traversed over system temporary table
       pages. The flush list scan now excludes system temporary
       table pages. (Bug #31060470, Bug #98974)

     * InnoDB: The buffer control block structure (buf_block_t)
       was freed while reducing the size of the buffer pool,
       causing an assertion failure. The fix for this bug also
       backports important aspects of the fix for Bug #20735882
       / Bug #76343, and replaces the internal
       buf_block_is_uncompressed() function with the
       buf_pointer_is_block_field_instance() function. The
       buf_block_is_uncompressed() function returned false in
       too many cases, affecting OLTP query throughput. (Bug
       #31036301, Bug #31389823)

     * InnoDB: Parallel read threads failed to respond to an
       explicit transaction interruption. (Bug #31016076)

     * InnoDB: In session started with START TRANSACTION WITH
       CONSISTENT SNAPSHOT, a range query returned a truncated
       result. The end range flag was not reset at the beginning
       of the index read resulting in an aborted read and
       missing rows. (Bug #30950714, Bug #98642)
       References: This issue is a regression of: Bug #23481444.

     * InnoDB: A full-text phrase search raised an assertion
       Thanks to TXSQL (Tencent MySQL) for the contribution.
       (Bug #30933728, Bug #31228694)
       References: This issue is a regression of: Bug #22709692.

     * InnoDB: A failure occurred while attempting to initialize
       the system tablespace on a raw disk partition.
       Additionally, a INPLACE DDL operation on the raw-disk
       partition tablespace failed with an error instead of
       switching to the COPY algorithm. (Bug #30867065, Bug

     * InnoDB: LOB purge code (lob::purge()) did not properly
       handle latches taken during B-tree mini-transaction
       (btr_mtr) commit and restore operations, which could lead
       to conflicts between B-tree and LOB mini-transactions.
       (Bug #30620011)

     * InnoDB: A long running statistics calculation operation
       on a large table blocked other operations requiring
       access to the table's statistics, causing those
       operations to fail. A new statistics calculation mutex
       was introduced, which permits concurrent access table
       Thanks to Kamil Holubicki for the contribution. (Bug

     * InnoDB: Two connections attempted to use the same
       transaction handler object resulting in a stalled query.
       (Bug #30594501)

     * InnoDB: Shutting down the server with
       innodb_fast_shutdown setting greater than 0 raised an
       assertion failure. The assertion was caused by the
       presence of recovered transactions that were not yet
       rolled back. Assertion code was revised to ignore
       recovered transactions during a fast shutdown. Messages
       are now written to the error log when recovered
       transactions that are not rolled back are left behind by
       a fast shutdown. Slow shutdown now waits for recovered
       transactions to be rolled back. Various other shutdown
       logic improvements were implemented. (Bug #30226841)

     * InnoDB: Dedicated log writer threads, introduced in MySQL
       8.0.11, caused a CPU-bound performance regression on
       low-concurrency systems. To address this issue, the new
       innodb_log_writer_threads variable permits disabling
       dedicated log writer threads so that redo log records are
       written from the log buffer to the system buffers and
       flushed from the system buffers to the redo log files by
       each user thread, which is the behavior prior to the
       introduction of dedicated log writer threads. Other redo
       logging optimizations were implemented, including the
       removal of an unnecessary log closer thread that wasted
       CPU time, and optimizations to remedy too-aggressive
       checkpoint activity and excessive flush calls. The issues
       addressed by this fix also manifested in a LOAD DATA
       performance regression. (Bug #30088404, Bug #30003849)

     * InnoDB: Restarting the server with an incorrect
       lower_case_table_names setting after a failure caused a
       hang condition. At startup, InnoDB waited for a
       transaction to roll back, but the rollback thread was not
       initiated due to a startup validation failure caused by
       the incorrect lower_case_table_names setting. (Bug

     * Replication: X Plugin could stop unexpectedly if a Group
       Replication notification was issued after a new X
       Protocol connection was made but before the session was
       created. The dispatcher thread that handles Group
       Replication notifications now checks that the session
       pointer is valid. (Bug #31742798)

     * Replication: Group Replication's handling of memory
       allocation issues when adding transaction write sets has
       been improved. (Bug #31586243)

     * Replication: You can now set the value of the gtid_purged
       system variable in a stored procedure, which was not
       previously permitted. You cannot set gtid_purged in a
       stored function. (Bug #31571427)

     * Replication: While a remote cloning procedure was taking
       place on a joining member during distributed recovery,
       Group Replication considered the pre-cloning
       gtid_executed value of the joining member when
       identifying the common set of transactions that had been
       applied on all members. This meant that garbage
       collection for applied transactions from the group's set
       of certification information (shown as the
       count_transactions_rows_validating field in the
       Performance Schema table replication_group_member_stats)
       did not take place during the remote cloning procedure.
       If the remote cloning procedure took a long time, the
       certification information could therefore get too large
       to transmit to the joining member when it restarted after
       the remote cloning procedure, in which case an error was
       raised and the member was not able to join the group.
       To avoid this issue, Group Replication now considers only
       group members with ONLINE status when identifying the
       common set of transactions that have been applied on all
       members. When a joining member enters ONLINE state after
       distributed recovery, its certification information is
       updated with the certification information from the donor
       at the time when the member joined, and garbage
       collection takes place for this on future rounds.
       As a workaround for this issue in earlier releases, after
       the remote cloning operation completes, wait two minutes
       to allow a round of garbage collection to take place to
       reduce the size of the group's certification information.
       Then issue the following statement on the joining member,
       so that it stops trying to apply the previous set of
       certification information:
RESET SLAVE FOR CHANNEL group_replication_recovery;

       (Bug #31446381, Bug #99778)

     * Replication: It was possible for a group member that left
       the group due to a communication error to reconnect
       between auto-rejoin attempts while the auto-rejoin
       procedure was still ongoing, which left Group Replication
       unable to function on the member. Group Replication's
       error management and member status handling has now been
       corrected to prevent this situation. (Bug #31401797)

     * Replication: When a replication source server shuts down
       and restarts, its MEMORY tables become empty. To
       replicate this effect to replicas, the first time that
       the source uses a given MEMORY table after startup, it
       logs an event that notifies replicas that the table must
       be emptied by writing a statement to the binary log to
       that effect. Previously, this was a DELETE statement, but
       it is now a TRUNCATE TABLE statement. A replica server
       also writes this statement to its own binary log when it
       shuts down and restarts. The statement is always logged
       in statement format, even if the binary logging format is
       set to ROW, and it is written even if read_only or
       super_read_only mode is set on the server. (Bug
       #29848785, Bug #95496)

     * Replication: When the system variable session_track_gtids
       was set to OWN_GTID on a multithreaded replica, the
       replica's performance would degrade over time and begin
       to lag behind the master. The cause was the buildup of
       the GTIDs recorded by the replica's worker threads at
       each transaction commit, which increased the time taken
       by the worker threads to insert new ones. Session state
       tracking is now disabled for worker threads on a
       multithreaded replica. Thanks to Facebook for the
       contribution. (Bug #29049207, Bug #92964)

     * Replication: When using row-based replication, the
       replica was allowed to use an invisible index when
       searching for rows to synchronize. (Bug #96148, Bug

     * Microsoft Windows: On Windows, build targets could fail
       if the build was on a file system root, such as R:/. (Bug

     * JSON: JSON_ARRAYAGG() did not always perform proper error
       handling. (Bug #31856260)

     * JSON: JSON_OBJECT() did not always perform proper
       checking for NULL values. (Bug #31393934)

     * The new WITH_SYSTEMD_DEBUG CMake option, if enabled,
       produces additional systemd debugging information, for
       platforms on which systemd is used to run MySQL. The
       default is OFF. (Bug #31788834)

     * For RPM and Debian packages, client-side plugins were
       moved from the server package to the client package in
       MySQL 8.0.21. This could cause failures relating to LDAP
       authentication plugins when upgrading from 5.7 packages
       to 8.0 packages. Packaging adjustments were made to avoid
       this problem. (Bug #31782612)
       References: This issue is a regression of: Bug #31123564,
       Bug #31336340.

     * The timestamp written for the ts key by the log_sink_json
       JSON-format error log sink did not have the same value as
       other timestamps in the same log message. (Bug #31749103)

     * Kerberos authentication for the SASL LDAP authentication
       plugin incorrectly handled failure to acquire a
       ticket-granting ticket. (Bug #31727195)

     * For some third-party libraries, enabling link-time
       optimization caused build failures. (Bug #31701553, Bug

     * Printing an excessively long diagnostic message could
       cause the server to exit unexpectedly. (Bug #31686926)

     * A page-compressed table was cloned as an uncompressed
       table. The associated tablespace object, which includes a
       compression flag, was not initialized prior to the
       cloning operation. (Bug #31677990, Bug #100243)

     * Certain cases of successful LDAP authentication could
       cause the server to hang. (Bug #31661437)

     * During transformation of a grouped query into a derived
       table, when the WHERE clause and the HAVING clause became
       part of the derived table, the condition count was not
       updated for the derived table. This resulted in reduced
       memory allocation while creating keys for ref access.
       (Bug #31661309)

     * When a value was compared using LIKE with a table column
       not defined as one of the MySQL string types, the server
       sometimes did not raise the expected error. (Bug

     * The acquire_related() service function returned the
       default service in some cases when it should have
       returned an error. (Bug #31655906)

     * In bootstrapping mode, certain multiple-statement
       transactions could cause unexpected server behavior. (Bug

     * A remote cloning operation checked for the availability
       of a plugin on the recipient that was removed from the
       donor instance previously. References to the uninstalled
       plugin had not been released. Error reporting issues
       related to plugin mismatches and availability were also
       addressed. (Bug #31639732, Bug #100244)

     * MySQL Server Docker images did not expose the Group
       Replication recommended port (33061). (Bug #31627536)

     * In debug builds, the server attempted to evaluate
       subqueries while creating a view. (Bug #31590301)
       References: This issue is a regression of: Bug #25466100.

     * A condition using RAND() was not pushed down even in
       cases where it was safe to do so, that is when no
       windowing function or GROUP BY is in use. (Bug #31587575)

     * While pushing conditions down to a derived table, a
       constant condition such as WHERE FALSE or WHERE TRUE was
       pushed down to the first table in the derived table,
       which is not necessary as the condition has nothing to do
       with the derived table. MySQL now avoids pushing constant
       conditions down to derived tables in such cases.
       In addition used tables are now updated for the condition
       that needs to be pushed down to the derived table,
       following code inspection revealing that this was not
       done after replacing the columns in the condition with
       the derived table expressions. (Bug #31587493)

     * A query using WHERE column > (... IN (SELECT ...)) could
       sometimes trigger an assertion in the range optimizer.
       (Bug #31586906)
       References: This issue is a regression of: Bug #30473261.

     * It was possible for ANALYZE TABLE to fail with Duplicate
       key error if a row was inserted in the interval between
       the check for the existence of the row and the execution
       of the insert, and the statistics table was updated
       concurrently. ANALYZE TABLE now ignores the error in this
       situation. (Bug #31582758)

     * The range optimizer does not use the correct lock type
       after cloning the handler needed to perform merged scans,
       and instead used a read lock unconditionally. This
       resulted in various different side effects for different
       For example, a SELECT with FOR UPDATE requests a write
       lock, but after cloning the handler for an index merge
       scan, the range optimizer requested a read lock which
       resulted in a mismatch. Similarly, for data dictionary
       tables, the lock type was set to LOCK_NONE due to the
       special handling required for such tables.
       To prevent this problem from occurring, we now ensure
       that the original lock type of the handler is always used
       in the cloned handler as well. (Bug #31582383)

     * In some cases, a query using an ANY subquery gave an
       incorrect result when the subquery_to_derived optimizer
       switch was enabled. (Bug #31566339)

     * When FALSE AND condition was simplified as FALSE,
       temporary table resources allocated for the condition
       were not always released afterwards. (Bug #31565009)

     * A value equal to ULLONG_MAX could be inserted into a
       BIT(64) column, but not retrieved. (Bug #31564742, Bug

     * While removing an unused window definition, a subquery
       that was part of an ORDER BY was not removed. The
       optimizer then tried to optimize the subquery without
       locking the tables. Now, when removing an unused window
       definition, the server cleans up any subqueries present
       as part of the definition. (Bug #31518806)
       References: This issue is a regression of: Bug #27062031.

     * Added a missing error code translation from ICU
       (Bug #31514995)

     * Merging during filesort operations could fail to remove
       duplicates for queries that used DISTINCT. (Bug
       #31498664, Bug #99900)

     * MySQL's internal DYNAMIC_STRING class formerly allocated
       memory in a linear fashion, that is, by a predetermined
       number of bytes. The class has been revised such that it
       now allocates memory exponentially, which should make
       operations such as repeated string appends more
       efficient. (Bug #31491799)

     * LOCK_mutex mishandling could result in a memory leak.
       (Bug #31491146)

     * A newly added collation was not added and could cause an
       unexpected exit on shutdown. (Bug #31470422)

     * On Windows, file name reuse by the GetTempFileName()
       function could cause an assertion to be raised. (Bug

     * A LATERAL subquery was incorrectly converted into an
       antijoin. (Bug #31465717)

     * NATURAL JOIN evaluation could inadvertently match hidden
       virtual columns created by functional indexes. (Bug
       #31463511, Bug #99807)

     * Sort keys for string hash join keys using more than 1024
       bytes were not handled correctly by the server. (Bug

     * The server attempted to delete from a view whose
       definition included HAVING when the HAVING clause was
       constant and evaluated as true even though a view with
       HAVING as part of its definition should not be updatable.
       (Bug #31429865)

     * Privilege requirements were checked incorrectly for the
       INFORMATION_SCHEMA.USER_ATTRIBUTES table. (Bug #31427410)

     * When the internal function replace_index_subquery()
       failed, the server still attempted to create iterators
       for the affected subquery. Now the function raises a
       clear error instead. (Bug #31427072)

     * A query using WHERE NOT EXISTS (SELECT const FROM table
       WHERE column=FROM_UNIXTIME(value) was not handled
       correctly. (Bug #31425664)

     * In some cases, key_hint handling was improperly applied
       to derived and internal temporary tables. (Bug #31424455)

     * Re-execution of prepared INSERT statements could fail for
       inserts through a view. (Bug #31417951)

     * JSON scalar evaluation could enter an infinite loop. (Bug

     * The user_attributes column in mysql.user table rows could
       be affected incorrectly by partial revokes. (Bug

     * Improper window function initialization could cause a
       server exit. (Bug #31389573, Bug #31437834)

     * Sensitive LDAP authentication plugin system variables now
       display as asterisks when retrieved in SQL statements.
       (Bug #31388444, Bug #31391864)

     * tests under no-threads connection
       handling failed with ASAN builds due to improper resource
       group initialization. This has been fixed. Thanks to
       Xiaoyu Wang, Tencent Technology for the contribution.
       (Bug #31378900, Bug #99609)

     * Using the authentication_ldap_simple authentication
       plugin with SSL could cause a segmentation fault during
       shutdown. (Bug #31364927)

     * Killing a query could raise spurious assertions in the
       hash join iterator. (Bug #31361354)

     * In some cases, an outer reference that was not LATERAL
       was not marked as read-only as expected. (Bug #31359965)

     * A failure occurred when upgrading from MySQL 5.7 to MySQL
       8.0 due to invalid references to orphaned events (events
       for which a database no longer exists). The server now
       fails with an appropriate error messages when orphaned
       events are encountered during upgrade. Error messages for
       orphaned stored routines were also revised. (Bug

     * Enabling the create_admin_listener_thread system variable
       could cause a server exit during startup. (Bug #31335279)

     * After ALTER TABLE to add an expression default to a
       column, the first insert inserted a value as if the
       expression had been evaluated at alter time and not
       insert time. (Bug #31330789, Bug #99513)

     * The LDAP authentication plugins did not properly compare
       the user-supplied authentication method against the
       permitted methods. (Bug #31320532)

     * Certain views could cause a following USE statement to
       result in an unexpected server exit. (Bug #31311312)

     * When a filesort sorted a buffer and LIMIT was active, it
       first sorted all rows and then discarded those that did
       not fit within the limit, which required sorting many
       rows that were certain to be discarded later. Now the
       optimizer sorts only the rows actually needed. Internal
       testing shows that this change can speed up the sort
       phase for a simple string sorting benchmark (as measured
       by EXPLAIN ANALYZE) by up to 15%. (Bug #31303537)

     * A dynamic range scan runs the range optimizer for each
       row fetched from the first table in a join to determine
       whether a range scan can be picked for the second table
       using the value available from that row. If the row
       contains no usable indexes, a table scan may be chosen
       instead. For the query giving rise to this issue, a table
       scan is chosen once, followed by a range scan on a
       non-covering index, and the dynamic range iterator has
       two read sets which are used for both these cases. One of
       these, used for the table scan, includes the base columns
       of generated columns required for processing the query;
       the other read set does not include the base columns in
       the read set used for range scans. This is because, for
       covering indexes, the read set should not include base
       columns to avoid adding unneeded columns by hash join or
       batched key access. The issue arose because the second
       read set was also used for a non-covering index, which
       resulted in an assert.
       To prevent this from happening, when initializing a table
       read set in the dynamic range iterator, we now make sure
       that it includes the base columns when the range
       optimizer picks a non-covering index. (Bug #31280526)
       References: This issue is a regression of: Bug #30417361.

     * It was possible to insert an out-of-range value for a
       TIMESTAMP if it included a timezone offset. (Bug

     * The keyring_hashicorp keyring plugin did not limit the
       size of keys for key operations. (Bug #31205715)

     * Configuring with -DWITH_ZSTD=system failed for older
       versions of the zstd library. CMake now checks the zstd
       version and requires at least 1.0.0 for compilation,
       1.2.0 to run compression checks. (Bug #31174920, Bug

     * In some cases, a SELECT that obtained status variable
       information from Performance Schema tables and that
       included a sort by a column containing temporal values
       was not handled correctly. (Bug #31168097)

     * In some cases, ROUND() and TRUNCATE() did not return the
       data type of their first arguments as expected. This fix
       insures that return types from these functions follow
       these rules, where the first argument is of the type

          + For any integer type, the return type is BIGINT.

          + For any floating-point type or any non-numeric type,
            the return type is DOUBLE.

          + For DECIMAL, the return type is also DECIMAL.

          + The type attributes for the return value are also
            copied from the first argument, except in the case
            of DECIMAL, when the second argument is a constant

          + When the desired number of decimal places is less
            than the scale of the argument, the scale and the
            precision of the result are adjusted accordingly. In
            addition, for the ROUND() function, the precision is
            extended by one place to accomodate rounding that
            increases the number of significant digits. If the
            second argument is negative, the return type is
            adjusted such that its scale is 0, with a
            corresponding precision.
       For more information, see the description of the ROUND()
       function. (Bug #31128028)

     * A SELECT ... FOR SHARE statement now only requires the
       SELECT privilege. Previously, the SELECT privilege was
       required with at least one of the DELETE, LOCK TABLES, or
       UPDATE privileges. (Bug #31096384, Bug #99101)

     * A semijoin strategy was chosen for the join of a
       correlated subquery having a LIMIT clause and requiring a
       row other than the first, which caused the LIMIT clause
       to be ignored and invalid rows to be returned. Now, when
       LIMIT used with this type of join specifies a row other
       than the first row, or more than one row, the semijoin
       strategy is no longer employed. (Bug #31096309)

     * After the fix for Bug #81009, privilege checks for
       truncating Performance Schema tables were too restrictive
       when read_only or super_read_only were enabled, causing
       truncation to fail even for users with appropriate table
       privileges. (Bug #31080309, Bug #99072)
       References: This issue is a regression of: Bug #81009.

     * ORDER BY did not work as expected for queries with ROLLUP
       in which window functions were also used. (Bug #31073133)

     * Some INSERT statements were not handled correctly. (Bug

     * Date interval calculations checked for overflow but not
       underflow. Now they check for both. (Bug #31054071)

     * Regular expression functions such as REGEXP_LIKE()
       yielded inconsistent results with binary string
       arguments. These functions now reject binary strings with
       an error. (Bug #31031886, Bug #98951, Bug #31031888, Bug

     * If an XA prepared transaction rollback XID was
       incorrectly formatted, the transaction remained in
       recovered state for XA COMMIT and XA ROLLBACK statements
       (or raised an assertion for debug builds) rather that
       reporting an error. (Bug #31030205)

     * Database-level privileges inherited through a role were
       not handled properly for database names that contained
       wildcard characters. (Bug #31013538, Bug #98876)

     * When the --local option was given, mysqlimport mishandled
       the MYSQL_OPT_LOAD_DATA_LOCAL_DIR option for
       mysql_options() so that it had no effect. (Bug #31001550)

     * Certain prepared statements could cause an unexpected
       server exit. (Bug #30943963)

     * OPTIMIZE TABLE for MyISAM tables could cause table size
       to increase and query performance to decrease. REPAIR
       TABLE for MyISAM tables could cause the Table is already
       up to date status produced by a previous OPTIMIZE TABLE
       to be lost. (Bug #30869674, Bug #98511, Bug #29755517)

     * mysqlpump object validation included objects in excluded
       databases. (Bug #30819012)

     * Inserting a TIMESTAMP value having a timezone offset
       which also had a zero for the month, day, or both, led to
       an assert. Such a value should be and is now rejected,
       regardless of the sql_mode setting. (Bug #30786762)
       References: See also: Bug #31239157.

     * Comparison of a TIME value with NULL in some cases raised
       an assertion. (Bug #30324587)
       References: This issue is a regression of: Bug #25949639.

     * LDAP authentication plugins enforced CA verification
       incorrectly, which could result in use of an incorrect
       CA. (Bug #30220357)

     * ORDER BY queries were not executed correctly when
       sort_buffer_size and max_sort_length were set to values
       which caused the internal limit on the maximum number of
       keys allowed per sort buffer to be set to 0. (Bug

     * A large number of nested arguments in full-text search
       query caused an error. (Bug #29929684)

     * A potential misreporting of memory use by the Performance
       Schema has been corrected. (Bug #29912403)

     * When explicit_defaults_for_timestamp was disabled and a
       NULL was inserted into a generated column declared as
       TIMESTAMP NOT NULL, the server would attempt to convert
       the inserted value to CURRENT_TIMESTAMP. Such an
       insertion is now rejected with ER_BAD_NULL_ERROR. (Bug

     * The SET_VAR hint did not accept a floating point value
       specified as a system variable setting. (Bug #29349748)

     * Previously, when NULL was used as the format argument to
       STR_TO_DATE(), irrelevant warnings were printed. Now,
       when NULL is passed to it, the function returns NULL.
       (Bug #27265863)

     * In some cases, incorrect use of IS NULL generated
       multiple warnings about invalid arguments. (Bug

     * Resolving an ORDER BY column that referred to a SELECT
       list column from a derived table was not performed
       correctly when executing certain prepared statements.
       (Bug #26808862)

     * When using EXPLAIN on a multi-table UPDATE statement in
       which a generated column was referenced in a condition,
       the output always showed the table containing this column
       as being updated, whether the table was actually updated
       or not. (Bug #22671310)

     * An assertion could be raised when the SQL layer passed
       incorrect information to InnoDB about the type of
       operation to be performed on a temporary table. (Bug

     * This construct works for base tables to insert a row
       using all default values but failed for views:

       (Bug #15988466, Bug #67863)

     * In some cases, the server issued an error when an
       invisible index was used in an index hint even when the
       use_invisible_indexes optimizer switch was not set to
       OFF. (Bug #100024, Bug #31550839)

     * When range values specified in a predicate are not
       compatible with the data type of the column with which
       the values are compared, the range optimizer rounds off
       the range values and assigns certain flags so that it
       does not exclude rows that qualify for the range because
       of rounding. In the specific query that triggered the
       reported issue, a column named id of type INT was tested
       using id NOT IN (-0.1, 0.1), and the values being tested
       are rounded to integers, with the predicate thus being
       treated as NOT IN (0,0). The optimizer then treats this
       as the intervals id < 0 and 0 < id < 0, but in this case
       it also set a flag to a value that indicated that reads
       should begin following rows containing 0 for the value to
       be compared. Now in such cases, the flag is set in such a
       way that the values which have been rounded are treated
       correctly. (Bug #98826, Bug #30988735)
       References: This issue is a regression of: Bug #80244,
       Bug #22661012.

     * For a view based on a join having an updatable part and
       one that was not, the error message generated when
       attempting to update a column of this view that was not
       updatable referenced the source table or view instead of
       the view actually named in the offending UPDATE
       statement. (Bug #80655, Bug #22891840)

Options: ReplyQuote

Written By
MySQL Community Server 8.0.22 has been released (part 2/2)
October 19, 2020 08: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.