MySQL Forums
Forum List  »  Announcements

MySQL Community Server 8.0.21 has been released (part 2/2)
Posted by: Bjørn Munch
Date: July 13, 2020 05:44AM

[ This is part 2 of the announcement ]

Bugs Fixed


     * InnoDB: A GROUP BY operation on a JSON array column
       caused failures in an UBSan build of MySQL due to
       incorrect type casting. (Bug #31451475)

     * InnoDB: Several InnoDB error log messages were defined
       without symbolic values. (Bug #31401028)

     * InnoDB: The file segment for a single page write was not
       released after a data file write failure associated with
       a doublewrite flush and sync operation. (Bug #31370227)

     * InnoDB: Code that was accessed when undo tablespace
       truncation used the same space ID before and after a
       truncate operation was removed. That scenario no longer
       occurs. The truncated undo tablespace is replaced by a
       new undo tablespace datafile with a different space ID.
       (Bug #31354435)

     * InnoDB: The range of reserved space IDs for undo
       tablespaces was increased from 512 per undo tablespace to
       400000. (Bug #31340834)

     * InnoDB: An error that occurred while inserting a log into
       the ddl_log table was not returned making it appear as
       though the operation was successful, and a transaction
       was not registered while performing a tablespace
       encryption operation. (Bug #31236217)

     * InnoDB: The lob::purge() function did not free LOBs
       correctly for an undo log record type
       (TRX_UNDO_UPD_DEL_REC) that is generated when an insert
       operation modifies a delete-marked record. (Bug
       #31222046, Bug #99339)

     * InnoDB: A shutdown error occurred following an attempt to
       rebuild a discarded partition. (Bug #31215415)

     * InnoDB: The internal get_real_path() function,
       responsible for retrieving directory or a file path, was
       modified to strip trailing separators before determining
       if a path is a file or directory. Additionally, if a path
       does not exist or cannot be identified as a file or
       subdirectory, the function now assumes the path is a file
       if the basename has a three letter suffix. (Bug
       #31215160)

     * InnoDB: Tablespace-related error messages were revised.
       (Bug #31205520, Bug #31205441)

     * InnoDB: To avoid potential compilation issues,
       __attribute__((const)) and __attribute__((pure))
       attributes were removed from internal InnoDB functions.
       (Bug #31153123)

     * InnoDB: The parallel read thread limit was not observed
       when spawning read threads for histogram sampling,
       causing an assertion failure. (Bug #31151218)

     * InnoDB: The transaction read view was not checked when
       sampling records for generation of histogram statistics.
       (Bug #31151077)

     * InnoDB: An I/O completion routine was not able acquire an
       LRU list mutex due to a latch held by another thread.
       (Bug #31128739)

     * InnoDB: An attachable transaction thread requested an
       InnoDB ticket that was already reserved by the main
       thread, causing a deadlock. Additionally, the server
       failed to respond to KILL statements in this deadlock
       scenario. (Bug #31090777)

     * InnoDB: The INNODB_METRICS table AVG_COUNT_RESET value
       for a counter defined as a module owner reported NULL.
       The METRIC_AVG_VALUE_RESET field was incorrectly marked
       as NULL.
       Thanks to Fungo Wang for the contribution. (Bug
       #31084706, Bug #98990)

     * InnoDB: At startup, following an unexpected stoppage
       during an undo tablespace truncate operation, some
       rollback segment header pages were found to be corrupted.
       Encryption of rollback segment header pages was initiated
       while the header pages were being written, resulting in
       some header pages not being encrypted, as expected. (Bug
       #31045160)

     * InnoDB: Various aspects of the lock system (lock_sys)
       code were refactored, and issues with lock_sys
       lock_rec_block_validate() and lock_test_prdt_pacge_lock()
       functions were fixed. The lock_rec_block_validate()
       function called another function repeatedly, which could
       result in locks not being validated under certain
       circumstances. The implementation also had a potential
       quadratic time complexity. The lock_test_prdt_page_lock()
       function did not iterate over all locks as intended. (Bug
       #31001732)

     * InnoDB: Use of memory-mapped files after exceeding the
       temptable_max_ram threshold caused a performance
       degradation. (Bug #30952983, Bug #98739)

     * InnoDB: In debug mode, a DROP TABLE operation on a table
       with an incorrectly defined COMPRESSION clause caused a
       failure. InnoDB did not return an error to the caller for
       proper handling. (Bug #30899683, Bug #98593)

     * InnoDB: Purge thread activity was excessive when the
       history list length approached zero, wasting CPU resource
       and causing mutex contention. (Bug #30875956)

     * InnoDB: A regression introduced in MySQL 8.0.18 affected
       INFORMATION_SCHEMA.INNODB_COLUMNS query performance.
       Schema and table data dictionary objects were fetched
       repeatedly to retrieve partition column information. (Bug
       #30837086, Bug #98449)
       References: This issue is a regression of: Bug #93033,
       Bug #28869903.

     * InnoDB: An ALTER TABLE ... IMPORT TABLESPACE operation
       with a .cfg file failed with an "Incorrect key file for
       table" error. The row_import::m_flags member was not
       initialized. (Bug #30830441)

     * InnoDB: A DROP TABLE operation performed after discarding
       a partition did not remove the associated data files, and
       DROP DATABASE failed with an error indicating that the
       database directory could not be removed. Upgrade from
       MySQL 5.7 to MySQL 8.0 also failed if a partitioned table
       with a discarded partition was present. The DISCARD
       attribute was applied to the table object instead of the
       partition object in the data dictionary, which made it
       appear that all partitions were discarded. (Bug
       #30818917)

     * InnoDB: The server failed intermittently with an "ibuf
       cursor restoration fails" error. (Bug #30770380, Bug
       #91033)

     * InnoDB: An ALTER TABLE operation that copied data from
       one table to another returned an "Out of range value for
       column" error. The counter that tracks the number of
       AUTO_INCREMENT rows required for a multi-row insert
       operation was not always set back to zero after a bulk
       insert operation. (Bug #30765952, Bug #98211)

     * InnoDB: The internal TempTable records_in_range() handler
       function contained a DBUG_ABORT() call that caused
       assertion failures in debug builds, and empty result sets
       in regular builds for some queries. (Bug #30716037)

     * InnoDB: The btr_cur_pessimistic_update() function failed
       to handle a cursor position change caused by a
       lob::purge() call. (Bug #30712878)

     * InnoDB: A type conversion failure during a DELETE IGNORE
       operation caused an assertion failure. A JSON value was
       not converted to the expected value. (Bug #30664660)

     * InnoDB: A purge operation encountered a null LOB
       reference, causing an assertion failure. (Bug #30658887)

     * InnoDB: Chunk size was not calculated correctly when
       deallocating memory from the TempTable storage engine,
       causing a regression in SELECT DISTINCT query
       performance. (Bug #30562964)

     * InnoDB: A segmentation fault occurred in the TempTable
       storage engine while using the thread pool plugin.
       TempTable thread-local variables were not compatible with
       the use of different threads for statements issued by a
       single client connection. Use of thread local variables
       also lead to excessive memory consumption due to the
       memory used by thread-local variables remaining allocated
       for the life of the thread. To address these issues,
       thread-local variables were replaced by a caching
       mechanism. (Bug #30050452, Bug #31116036, Bug #99136)

     * InnoDB: A fatal "page still fixed or dirty" error
       occurred during shutdown. (Bug #29759555, Bug #95285)
       References: This issue is a regression of: Bug
       #330065518.

     * Partitioning: A query against a partitioned table, which
       used an ORDER BY, returned unordered results under the
       following conditions:

          + The table had a composite index with a prefix on one
            of the columns.

          + The query's WHERE clause contained an equality
            condition on the prefixed column.

          + The column with the prefix was the leftmost column
            in the index.

          + The column used in the ORDER BY was the rightmost
            column in the index.

          + The index was used for handling the ORDER BY.
       Our thanks to Quanan Han for the contribution. (Bug
       #84070, Bug #25207522)

     * Replication: A global value that is set for the
       group_replication_consistency system variable, which
       controls all user connections, is applied on Group
       Replication's internal connections to MySQL Server
       modules using the SQL API, which are handled in a similar
       way to user connections. This could sometimes lead to
       Group Replication reporting the use of
       group_replication_consistency as an error, for example
       when checking the clone plugin status during distributed
       recovery. Group Replication's internal connections using
       the SQL API are now configured to use the consistency
       level EVENTUAL, which matches the behavior before the
       group_replication_consistency option was available, and
       does not cause an error message. (Bug #31303354, Bug
       #99345)

     * Replication: If a group's consistency level (set by the
       group_replication_consistency system variable) was set to
       BEFORE or BEFORE_AND_AFTER, it was possible for a
       deadlock to occur in the event of a primary failover. The
       primary failover is now registered differently to avoid
       this situation. (Bug #31175066, Bug #98643)

     * Replication: On Windows, Group Replication's use of the
       Windows API function SleepConditionVariableCS to wait for
       new write events caused noticeably high CPU usage by this
       function after Group Replication had been running for two
       days or more, which could be corrected by restarting the
       MySQL server instance, but then increased again over time
       as before. This was caused by the use of two clock
       functions to calculate the timeout after which the
       SleepConditionVariableCS function was called, which
       drifted relative to each other over time, making the
       timeout progressively shorter and the calls to the
       function more frequent. The issue has been corrected on
       Windows by using the current time from a single clock to
       calculate the timeout. (Bug #31117930)

     * Replication: If Group Replication was stopped while
       distributed recovery was in progress, memory issues could
       result from an attempt to access the record of the member
       that was selected as the donor. This record is now kept
       locally with the distributed recovery state. (Bug
       #31069563)

     * Replication: When distributed recovery for Group
       Replication involves a remote cloning operation, the flag
       set on the server to indicate this remains set until the
       server instance is restarted. Previously, if Group
       Replication was stopped and restarted on the server, that
       flag caused Group Replication to purge the relay log
       files for the group_replication_applier channel, as is
       required on starting after a remote cloning operation to
       ensure that there is no mismatch with the cloned data
       tables. If there were any unapplied transactions in the
       purged relay log files, the member could not subsequently
       be used to bootstrap a group, although it could
       successfully join a group by retrieving the transactions
       from another member. Group Replication now ignores the
       flag on its second or subsequent starts, and only purges
       the relay log files the first time it is started after a
       remote cloning operation. (Bug #31059680)

     * Replication: To avoid the possibility of data
       inconsistency, Group Replication blocks a new incarnation
       of the same server (with the same address but a new
       identifier) from joining the group while its old
       incarnation is still listed as a member. Previously,
       Group Replication's Group Communication System (GCS)
       treated the connection to the old incarnation of a server
       as active while it was attempting to send messages to the
       server, and only recognized that the connection was
       inactive when the socket returned an error, which might
       take a significant amount of time. During that period,
       the new incarnation of the server was unable to join the
       group because the existing members did not connect to it,
       as they were still waiting on the connection to the old
       incarnation. Now, GCS only treats a connection to a
       server as active while messages can be sent to it
       successfully. If the socket is no longer writeable, the
       server connection is treated as inactive and is
       proactively closed. The connection close triggers the
       group member to attempt reconnection to that server
       address, upon which a connection is established to the
       new incarnation of the server, enabling the new
       incarnation to join the group. (Bug #30770577)

     * Replication: Group Replication did not broadcast a
       notification when switching from single-primary mode to
       multi-primary mode. The change is now notified for use in
       routing. (Bug #30738896)

     * 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
       notifies replicas that the table must be emptied by
       writing a DELETE statement for that table to the binary
       log. Previously, the generated DELETE statement was
       written to the binary log statement cache for the current
       session, which could result in it being logged together
       with other statements under the same GTID, or logged
       without BEGIN and COMMIT statements. Also, in some
       situations, the generated DELETE statement could consume
       the GTID intended for the transaction that triggered it.
       The generated DELETE statement is now logged with
       accompanying BEGIN and COMMIT statements, and the
       resulting transaction is flushed to the binary log
       immediately after it is written to the statement cache,
       so that it always receives its own GTID and is kept
       separate from other transactions. (Bug #30527929, Bug
       #25681518, Bug #77729)

     * Replication: Following a patch in MySQL 8.0.14, if a
       function call contained operations on temporary tables,
       it could be written to the binary log in statement format
       when binlog_format = MIXED was set. This led to CREATE
       TEMPORARY TABLE statements being incorrectly written to
       the binary log if they contained a function call.
       Following further analysis, operations on temporary
       tables in stored functions and triggers are now marked as
       unsafe for binary logging in statement format, as they
       have a strong chance of causing issues with replication.
       When binlog_format = MIXED is set, these operations are
       now logged in row format. (Bug #30395151, Bug #30320009)

     * Replication: Setting the group_replication_force_members
       system variable to force a specified membership for a
       group could fail if another member had already requested
       the expulsion of the member that was driving the
       group_replication_force_members operation. The operation
       to implement the configuration specified by the
       group_replication_force_members system variable forced
       any pending group reconfigurations to take place first.
       If one of those successfully expelled the member where
       the system variable had been set, because the expel
       timeout that was set on the member had expired, the
       operation timed out and failed to complete. To avoid this
       situation, Group Replication now proceeds directly to
       implementing the new configuration specified by the
       group_replication_force_members system variable, and
       ignores any other pending group reconfigurations. (Bug
       #29820966)

     * Replication: A fix made in MySQL 8.0.14 and MySQL 5.7.25
       for a deadlock scenario involving the system variables
       binlog_transaction_dependency_tracking and
       binlog_transaction_dependency_history_size had the side
       effect of leaving the writeset history used for
       transaction dependency tracking unprotected from
       concurrent update. The writeset history and tracking mode
       are now locked correctly whenever they are accessed. (Bug
       #29719364, Bug #95181)
       References: See also: Bug #28511326, Bug #91941.

     * Replication: If a CHANGE MASTER TO statement was issued
       with MASTER_USER specified as empty (MASTER_USER=''), the
       statement succeeded and cleared any previously specified
       user name in the replication metadata repositories.
       However, if information was subsequently read from the
       repositories, for example during an automatic restart of
       a Group Replication channel, a default user name could be
       substituted for the channel. This issue has now been
       fixed, so from MySQL 8.0.21, it is a valid approach to
       set an empty MASTER_USER user name if you always provide
       user credentials using the START SLAVE statement or START
       GROUP_REPLICATION statement that starts the replication
       channel. This approach means that the replication channel
       always needs operator intervention to restart, but the
       user credentials are not recorded in the replication
       metadata repositories.
       The documentation for the CHANGE MASTER TO statement has
       also been corrected to clarify that it is possible to
       specify MASTER_USER='', and the resulting error occurs
       only if you attempt to start the replication channel with
       the empty credentials. (Bug #27357189)

     * Replication: Group Replication's tracking of connections
       to other group members only took into account the
       incoming connections, not the outgoing connections. This
       meant if the outgoing connection from member A to member
       B was broken, for example by a firewall configuration
       issue, but the incoming connection from member B to
       member A was intact, member A would display member B's
       status as ONLINE, although member A's messages were not
       reaching member B. Member B would display member A's
       status as UNREACHABLE. Now, if a group member starts to
       receive pings from another group member to which it has
       an active connection (in this case, if member A received
       pings from member B), this is treated as an indicator of
       an issue with the connection. If sufficient pings are
       received, the connection is shut down by the recipient of
       the pings (in this case, member A), so that the status of
       the connection is consistent for both members. (Bug
       #25660161, Bug #84796)

     * JSON: When the expression and path passed to JSON_TABLE()
       yielded a JSON null, the function raised an error instead
       of returning SQL NULL as required. (Bug #31345503)

     * JSON: In MySQL 5.7, and in MySQL 8.0 prior to 8.0.17, the
       server attempted to convert JSON boolean values to their
       SQL counterparts when testing them directly with IS TRUE,
       as shown here:
mysql> CREATE TABLE test (id INT, col JSON);

mysql> INSERT INTO test VALUES (1, '{"val":true}'), (2, '{"val":false}
');

mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TR
UE;
+------+---------------+--------------+
| id   | col           | col->"$.val" |
+------+---------------+--------------+
|    1 | {"val": true} | true         |
+------+---------------+--------------+

       As the result of work done in MySQL 8.0.17 to ensure that
       all predicates in SQL conditions are complete (that is, a
       condition of the form WHERE value is rewritten as WHERE
       value <> 0), and that a NOT IN or NOT EXISTS condition in
       a WHERE or ON clause is converted to an antijoin,
       evaluation of a JSON value in an SQL boolean context
       performs an implicit comparison against JSON integer 0.
       This means that the query shown previously returns the
       following result in MySQL 8.0.17 and later:
mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TR
UE;
+------+----------------+--------------+
| id   | col            | col->"$.val" |
+------+----------------+--------------+
|    1 | {"val": true}  | true         |
|    2 | {"val": false} | false        |
+------+----------------+--------------+

       In such cases, the server also now provides a warning:
       Evaluating a JSON value in SQL boolean context does an
       implicit comparison against JSON integer 0; if this is
       not what you want, consider converting JSON to a SQL
       numeric type with JSON_VALUE RETURNING. Thus, the query
       can now be rewritten using JSON_VALUE() as shown here:
mysql> SELECT id, col, col->"$.val" FROM test
    ->     WHERE JSON_VALUE(col, "$.val" RETURNING UNSIGNED) IS TRUE;
+------+---------------+--------------+
| id   | col           | col->"$.val" |
+------+---------------+--------------+
|    1 | {"val": true} | true         |
+------+---------------+--------------+

       (Bug #31168181)

     * JSON: A GROUP BY query against a table having a
       multi-valued index was not always handled correctly by
       the server. (Bug #31152942)

     * If log_error_services was persisted, in some cases it
       could take effect at the wrong time during startup. (Bug
       #31464539)

     * SHOW CREATE USER after certain manual grant table
       modifications could cause a server exit. (Bug #31462844)

     * Some in-memory updates of partial revokes could produce
       incorrect privileges. (Bug #31430086)

     * If log_error_verbosity was set using SET PERSIST, it did
       not take effect early enough during server startup to
       affect InnoDB initialization. (Bug #31410674)

     * The parser incorrectly raised an assertion before
       rejecting subqueries in generated column expressions.
       (Bug #31396191)

     * This release makes the following two micro-optimizations
       for degenerate hash joins (that is, those with no join
       conditions):

         1. For a degenerate hash antijoin or semijoin, add
            LIMIT 1 when building the hash table, since having
            more rows than this cannot change the result.

         2. For a degenerate hash antijoin with a nonempty hash
            table, avoid scanning the outer side.
       Together, these changes handle a performance regression
       whereby a rewrite to a hash antijoin caused a NOT EXISTS
       query which was not rewritten to be executed by the
       optimizer and be replaced with "zero rows found". To
       handle the case in which a nested loop is used instead, a
       non-correlated subquery inside NOT EXISTS is no longer
       transformed to an antijoin.
       This fix also applies to subqueries using constant NOT IN
       (non_correlated_subquery). (Bug #31376809)

     * Configuring with -DWITH_EDITLINE=system resulted in
       compilation failures for older library versions. (Bug
       #31366715)

     * The upgrade of the bundled libedit library in the
       previous MySQL distribution caused a problem for builds
       using that library such that CTRL+C (SIGINT) in the mysql
       client required a following Enter to take effect in some
       circumstances. (Bug #31360025)

     * Columns declared with both AUTO_INCREMENT and DEFAULT
       value expressions are a nonpermitted combination, but
       ALTER TABLE failed to produce an error for SET DEFAULT
       (expr) operations on AUTO_INCREMENT columns. (Bug
       #31331454)

     * It was possible to set the
       protocol_compression_algorithms system variable to the
       empty string. This is no longer permitted. (Bug
       #31326231)

     * A lookup function used internally in the MySQL server
       returns integer -1 when the argument is ambiguous; this
       resulted in undefined behavior when this value was
       converted to an unsigned value prior to use as an
       argument in subsequent calculations. Now when the
       function returns -1, this is handled as an error and the
       value is not used further. (Bug #31326120)

     * Negation of a signed value in certain cases led to
       undefined behavior; to prevent this from occurring, the
       value to be negated is now treated as unsigned. (Bug
       #31325602)

     * The WEIGHT_STRING() function did not always return the
       correct result for an integer argument. (Bug #31321257)
       References: This issue is a regression of: Bug #30776132.

     * Assigning CONCAT('') or CONCAT_WS('') to a variable set
       the variable to NULL, not the empty string. (Bug
       #31320716, Bug #99485)

     * Corrected problems where under some circumstances
       privilege restrictions could be ignored. (Bug #31306814,
       Bug #31315692)

     * Certain SELECT statement privileges to lock rows were not
       checked properly and could block other users incorrectly.
       (Bug #31293065)

     * When performing a filesort, an internal function could
       sometimes return NULL on failure, even if the subselect
       being sorted was not nullable. (Bug #31281602)

     * Statement rewriting for the binary log was inefficient on
       Windows. (Bug #31260698)
       References: This issue is a regression of: Bug #30654405.

     * An inconsistency in representing anonymous users in
       memory could cause issues while performing
       privilege-granting operations. (Bug #31246179)

     * If the administrative connection interface was enabled, a
       race condition could lead to problems accepting Unix
       socket file connections on the main connection interface.
       (Bug #31241872)

     * When a role was granted with WITH ADMIN OPTION, the
       grantee was able to manage the role only after activating
       it. (Bug #31237368)

     * Invalid rows in the default_roles or role_edges system
       tables could cause server misbehavior. (Bug #31217385)

     * Component deinitialization failure at runtime could lead
       to repeated messages written to the error log at
       shutdown. (Bug #31217037)

     * The prohibition on granting roles to anonymous users was
       incompletely enforced. (Bug #31215017)

     * A privilege-escalation issue was corrected. (Bug
       #31210226)

     * The keyring_hashicorp keyring plugin did not perform
       sufficient validity checking on the values of its
       configuration parameters. (Bug #31205363)

     * The keyring_hashicorp keyring plugin did not permit
       binary log encryption to be enabled (by setting the
       binlog_encryption system variable). (Bug #31204841)

     * The keyring_hashicorp keyring plugin did not permit an
       encryption password to be set by the audit_log plugin.
       (Bug #31197670)

     * Some queries using REGEXP_SUBSTR() with an ORDER BY
       clause were not handled correctly by the server. (Bug
       #31184858)

     * Some instances where pointer arithmetic was applied to
       nullptr were corrected. (Bug #31172750)

     * If the available file descriptors were exhausted,
       mysql_real_connect() caused the client to exit. (Bug
       #31151052)

     * Using the killall command to initiate a mysqld shutdown
       resulted in no message being logged to indicate the start
       of shutdown. This has been corrected. (Bug #31121907)

     * Calling mysql_real_connect_nonblocking() with an invalid
       host could cause the client to exit upon calling
       mysql_close(). (Bug #31104389, Bug #99112)

     * For Debian packages, Python 2 dependencies that could
       cause installation failures were removed. (Bug #31099324)

     * A potential memory leak in lf_hash_insert() was fixed.
       (Bug #31090258, Bug #99078)

     * Within the LDAP SASL authentication plugins, multiple
       calls to sasl_client_done() could cause undefined
       behavior in some cases. (Bug #31088206)

     * With the thread pool plugin enabled, high concurrency
       conditions could cause loss of client context resulting
       in a server exit. (Bug #31085322)

     * For result sets processed using mysql_use_result(),
       mysql_fetch_row_nonblocking() did not increment the
       number of rows, so that after all the rows were fetched,
       mysql_num_rows() returned an incorrect number of rows.
       (Bug #31082201, Bug #99073)

     * Removed an unneeded optimization for EXISTS() that was
       never actually evaluated. (Bug #31069510)

     * For a server started with the --skip-grant-tables option,
       enabling the partial_revokes system variable caused a
       server exit. (Bug #31066069, Bug #31202963)

     * Queries that used a recursive common table expression
       with an outer reference could return incorrect results.
       (Bug #31066001, Bug #99025)

     * The parser could fail for multibyte character sets with a
       minimum character length greater than 1 byte. (Bug
       #31063981)

     * In some cases, the LEAST() function could return NULL for
       non-nullable input. (Bug #31054254)
       References: This issue is a regression of: Bug #25123839.

     * mysql_real_connect_nonblocking() blocked if the
       MYSQL_OPT_CONNECT_TIMEOUT option was set. (Bug #31049390,
       Bug #98980)

     * The last call to the mysql_fetch_row_nonblocking() C API
       function to return the null row was setting an error when
       it should not have. (Bug #31048553, Bug #98947)

     * On Windows, the default connection type uses a named
       pipe. The nonblocking C API, which is intended for
       TCP/SSL connections, did not take that into account and
       caused the client to exit. It now produces an error
       message indicating the problem. (Bug #31047717)

     * X Plugin connections that failed to authenticate due to
       nonexistence of the user modified the global
       audit_log_filter_id system variable. (Bug #31025461)

     * LOAD DATA did not ignore hidden generated columns when
       parsing input file rows. (Bug #31024266, Bug #98925)

     * Pinbox exhaustion in the metadata locking subsystem could
       produce a misleading error message. (Bug #31019269, Bug
       #98911)

     * CREATE TABLE ... SELECT failed if it included a
       functional index. (Bug #31017765, Bug #98896)

     * For X Protocol connections, checking the global session
       mutex was improved to eliminate a minor performance
       degradation as the number of threads increased. (Bug
       #31000043)

     * In certain cases, executing a query containing multiple
       subqueries could lead to an unplanned shutdown of the
       server. (Bug #30975826)

     * SHOW CREATE TRIGGER failed if FLUSH TABLES WITH READ LOCK
       was in effect. (Bug #30964944)

     * Excessive access checks were performed on certain of the
       data dictionary tables that underlie INFORMATION_SCHEMA
       views, resulting in slow SHOW COLUMNS performance. These
       checks were reduced to improve performance.
       In addition, several SHOW statements implemented as
       INFORMATION_SCHEMA queries were found to benefit from
       enabling the derived_merge flag for the optimizer_switch
       system variable. Such queries now internally enable that
       flag temporarily for better performance, regardless of
       the flag session value. Affected queries are:
SHOW SCHEMAS
SHOW TABLES
SHOW TABLE STATUS
SHOW COLUMNS
SHOW KEYS
SHOW EVENTS
SHOW TRIGGERS
SHOW PROCEDURE STATUS
SHOW FUNCTION STATUS
SHOW CHARACTER SET
SHOW COLLATION

       (Bug #30962261, Bug #98750, Bug #30921214)

     * Two otherwise identical queries executed separately
       returned one row when using a case-sensitive collation
       and two rows with a case-insensitive collation. When the
       same two predicates were combined in a single query using
       AND, two rows were returned when only one row should have
       been. (Bug #30961924)

     * ALTER TABLE on a SET column that had a display width
       greater than 255 was not done in place, even if otherwise
       possible. (Bug #30943642, Bug #98523)

     * The server checked whether a number in yottabytes was too
       large to print by comparing the value as a double to
       ULLONG_MAX, which cannot be represented as a double. This
       caused the double value immediately above ULLONG_MAX
       yottabytes to be printed as 0Y, the erroneous conversion
       being reported by Clang 10. (Bug #30927590)

     * Resource group SQL statements such as CREATE RESOURCE
       GROUP did not work over connections that use X Protocol.
       (Bug #30900411)

     * SHOW GRANTS could display function privileges as
       procedure privileges. (Bug #30896461, Bug #98570)

     * The audit_log plugin mishandled connection events when
       multiple clients connected simultaneously. (Bug
       #30893593)

     * The LOCK_ORDER tool reported a syntax error for empty
       dependency graphs. Empty graphs are now permitted.
       The LOCK_ORDER tool could exhibit unexpected behavior due
       to mishandling thread list maintenance. (Bug #30889192)

     * Upgrades from MySQL 5.7 did not grant the
       REPLICATION_APPLIER privilege to root. (Bug #30783149)

     * The gen_range() user-defined function could mishandle its
       arguments, causing a server exit. (Bug #30763294)

     * During UPDATE processing, conversion of an internal
       in-memory table to InnoDB could result in a key-length
       error. (Bug #30674616)

     * Attempts to grant dynamic privileges (which are always
       global) at the procedure or function level did not
       produce an error. (Bug #30628160)

     * Table value constructors ignored the LIMIT clause. The
       clause is now taken into account. For example: VALUES
       ROW(1), ROW(2), ROW(3) LIMIT 2 outputs 1 and 2. (Bug
       #30602659)

     * It is possible to define a column named * (single
       asterisk character), but SELECT `*` was treated
       identically to SELECT *, making it impossible to select
       only this column in a query; in other words, the asterisk
       character was expanded to a list of all table columns
       even when it was surrounded by backticks. (Bug #30528450)

     * The FROM_DAYS() function could produce results that were
       out of range (with the year > 9999). (Bug #30455845, Bug
       #97340)

     * Privileges on the INFORMATION_SCHEMA.FILES table were
       being checked incorrectly. (Bug #30350829)

     * For debug builds, altering the mysql.func table to MyISAM
       (not a recommended operation in any case) caused a server
       exit. Now this operation is prohibited. (Bug #30248138,
       Bug #96692)

     * Queries on the INFORMATION_SCHEMA KEY_COLUMN_USAGE and
       TABLE_CONSTRAINTS views could be slow due to UNION use in
       their definitions. These were rewritten to move the UNION
       into a LATERAL table to enable the optimizer to better
       use indexes. (Bug #30216864, Bug #30766181, Bug #98238)

     * In certain cases, a LIMIT clause incorrectly caused the
       optimizer to estimate that zero rows needed to be read
       from a table. (Bug #30204811)
       References: This issue is a regression of: Bug #29487181.

     * An internal packet-length function returned values of the
       wrong integer type. (Bug #30139031)

     * Calculations by mysqldump for the length of INSERT
       statements did not take into account the _binary
       character set introducer used for VARBINARY strings. (Bug
       #29998457, Bug #96053)

     * The messages printed to the error log during upgrade of
       partitioned tables defined with prefix keys did not
       provide sufficient details. Detailed warnings that
       indicate the schema, table, column, and prefix length are
       now printed. (Bug #29942014)
       References: See also: Bug #31100205.

     * mysql_store_result() could fail to detect invalid data
       packets. (Bug #29921423)

     * An assertion was raised if creating a child table in a
       foreign key relation caused an engine substitution. (Bug
       #29899151, Bug #95743)

     * mysqltest and mysql-test-run.pl no longer support the
       --sleep command-line option. mysqltest no longer supports
       the real_sleep command. (Bug #29770237)

     * The server permitted connections for hosts with names
       longer than the maximum permitted length (255
       characters). (Bug #29704941)

     * In a multiple-table UPDATE that updated the key of the
       first table, if a temporary table strategy was used,
       duplicate entries could be written to the temporary
       table, followed by occurrence of a Can't find record
       error. (Bug #28716103)

     * The server sometimes mistakenly removed a subquery with a
       GROUP BY when optimizing a query, even in some cases when
       this subquery was used by an outer select. This could
       occur when the subquery also used an aggregate function.
       (Bug #28240054)

     * Coercibility of the NAME_CONST() function was assessed
       incorrectly. (Bug #26319675)

     * When reading rows from a storage engine, errors other
       than "no more records" could be ignored, leading to
       problems later. (Bug #20162055)

     * When a multi-table update used a temporary table, this
       was not shown in the output of EXPLAIN FORMAT=TREE, even
       though such use could have an impact on the performance
       of the UPDATE statement for which this was done. (Bug
       #17978975)

     * When performing a filesort for removing duplicates, such
       as when executing SELECT DISTINCT, it may be necessary to
       perform another sort afterwards to satisfy an ORDER BY.
       In cases where such an ORDER BY had been pushed down into
       the first table of a join, as opposed to the join as a
       whole, this final sort was not actually performed. (Bug
       #99687, Bug #31397840)

     * Refactoring work done in MySQL 8.0.20 caused single-row
       buffering for GROUP BY of non-nullable columns not to
       function correctly, not taking into account that such a
       column could be the inner table for an outer join, and
       thus would have a NULL flag that would need to be copied.
       In a GROUP BY without a temporary table, this would cause
       the NULL flag to come from the next output row instead of
       the previous one, and the data returned to be
       inconsistent. (Bug #99398, Bug #31252625)
       References: This issue is a regression of: Bug #30460528.

     * A logical error in the constant folding code for the case
       in which a constant of type DECIMAL or FLOAT was the
       left-hand operand and an integer column value was the
       right-hand operand yielded an incorrect result. (Bug
       #99145, Bug #31110614)

     * A query whose predicate compared 0 with -0 where at least
       one of these was a floating-point value returned
       incorrect results. (Bug #99122, Bug #31102789)

     * SELECT DISTINCT( HEX( WEIGHT_STRING(varchar_column) ) )
       returned a truncated result. (Bug #98592, Bug #30898753)

     * Problems with error handling in queries with MAX(),
       MIN(), or both, combined with a GROUP BY clause, meant
       that such a query continued executing until it went
       through all possible iterations even when an error should
       have caused it to terminate immediately. (Bug #98242, Bug
       #30769515)

     * Reimplemented rollups without using slices. This fixes
       the following known issues:

          + A repeating column in a GROUP BY ... WITH ROLLUP
            yielded the wrong result; that is, a GROUP BY of the
            form GROUP BY a, b, a WITH ROLLUP erroneously
            produced NULL for some of the column names in the
            result.

          + A GROUP BY ... WITH ROLLUP that did not require a
            temporary table to print the result also produced an
            erroneous NULL in place of at least one of the
            expected column names in the output.
       (Bug #96768, Bug #30967158, Bug #26227613, Bug #30969045,
       Bug #29134467)

     * After refactoring the type propagation code for LEAST(),
       GREATEST(), and other functions, as well as UNION, an
       adjustment of the result type for data types like ENUM
       also replaced the calculated integer data type with a
       type that could not accommodate both signed and unsigned
       values. (Bug #95148, Bug #29698617)
       References: This issue is a regression of: Bug #83895,
       Bug #25123839.

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Community Server 8.0.21 has been released (part 2/2)
1555
July 13, 2020 05:44AM


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.