Documentation Home
MySQL 8.0 Release Notes
Related Documentation Download these Release Notes
PDF (US Ltr) - 4.2Mb
PDF (A4) - 4.2Mb


MySQL 8.0 Release Notes  /  Changes in MySQL 8.0.38 (2024-07-01, General Availability)

Changes in MySQL 8.0.38 (2024-07-01, General Availability)

Important

This release is no longer available for download. It was removed due to a critical issue that could stop the server from restarting following the creation of a very large number of tables (8001, or more). Please upgrade to MySQL 8.0.39 instead.

Audit Log Notes

  • Audit log pruning did not function after removing or renaming a file from the audit log. Now pruning continues in such cases, but with a warning printed in the error log stating that it was not possible to delete the missing audit log file. (Bug #35902913)

C API Notes

  • C API applications stalled while receiving results for server side prepared statements.

Compilation Notes

  • Upgraded the bundled googletest and googlemock sources to version 1.14.0. (Bug #36562482)

  • Added a missing dependency on GenError. (Bug #36551721)

  • It is now possible on Linux systems to build MySQL using a bundled tcmalloc library that is provided with the source by specifying -DWITH_TCMALLOC=BUNDLED. This is supported on Linux only. (Bug #36313839)

  • The bundled tcmalloc() is now used when building MySQL on Enterprise Linux 8. (Bug #114844, Bug #35674008)

  • Linux aarch64 platform binaries are now built using patchelf --page-size=65536 for compatibility with systems using either 4k or 64k for the page size. (Bug #114233, Bug #36393794)

Connection Management Notes

  • The conn_delay/Waiting in connection_control plugin stage was not reset after a delay introduced by the connection control plugin which resulted in incorrect monitoring information. (Bug #35205358)

Data Dictionary Notes

  • Attempting to upgrade a MyISAM table containing a mix of regular columns and generated columns from MySQL 5.7 to 8.0 or later led to table corruption. (Bug #105301, Bug #33503328)

Pluggable Authentication

  • The deprecation warning issued when authenticating with the mysql_native_password plugin is now issued only once. (Bug #35792948)

Thread Pool Notes

  • Connecting to a thread group that had no connection handler threads stalled. We fix this by making sure that connection handler threads terminate only if there is at least one connection thread left. (Bug #36550125)

Bugs Fixed

  • InnoDB: MySQL unexpectedly halted on an UPDATE after an ALTER TABLE operation. (Bug #36571091)

    References: This issue is a regression of: Bug #35183686.

  • InnoDB: The log index size calculation now accounts for column order changes. (Bug #36526369)

    References: This issue is a regression of: Bug #35183686.

  • InnoDB: File system operations performed by InnoDB now consistently fsync the parent directory when performing directory altering tasks. (Bug #36174938)

  • InnoDB: In debug builds, setting the innodb_interpreter_output debug variable would cause the server to unexpectedly halt. This is now a read-only variable. (Bug #36041032)

  • InnoDB: For tables created with an index on a column that was too wide for the redundant row format (allowed before MySQL 5.7.35), an in-place upgrade silently imported the table but it was not accessible, which interfered with making backups. Now all operations that involve using the invalid index are rejected with ER_INDEX_CORRUPT until the index is dropped. An ER_IB_INDEX_PART_TOO_LONG error is also reported in the error log. (Bug #35869747)

    References: See also: Bug #34826861.

  • InnoDB: An InnoDB assertion error referencing an invalid column index was triggered when the column index was valid. (Bug #34800754)

  • InnoDB: With an empty XA transaction, shutting the server down after an XA START would cause the server to halt unexpectedly. (Bug #32416819)

  • InnoDB: Shutting down the replication applier or binlog applier while processing an empty XA transaction caused the system to unexpectedly halt. (Bug #32416819)

  • InnoDB: Removed unnecessary heap usage in the Validate_files::check() function.

    Our thanks to Huaxiong Song for the contribution. (Bug #115041, Bug #36626203)

  • InnoDB: If a partition table was read with innodb_parallel_read_threads=1, read performance greatly decreased from any table after 256 reads. InnoDB behaved as if it reached the maximum capacity of parallel read threads despite not using any.

    Our thanks to Ke Yu for the contribution. (Bug #114154, Bug #36347408)

  • InnoDB: The result from a spatial index containing a column with a spatial reference identifier (SRID) attribute was empty. In addition, using FORCE INDEX to force a covering index scan on a spatial index led to an assertion. (Bug #112676, Bug #114200, Bug #35894664, Bug #36361834)

  • InnoDB: Fixed performance issues related to querying the data_lock and data_lock_waits tables when thousands of read-only transactions were present. (Bug #109539, Bug #34951273)

  • Replication: If a source contained a stored, generated column populated by a JSON function and binlog_row_image was set to MINIMAL, any subsequent update or deletion on the underlying column failed with the following error:

            Invalid JSON text in argument 1 to function json_extract: 'The document is empty.'

    The replica attempted to re-evaluate the generated column and failed with that error because the underlying column was unavailable. As of this release, stored, generated columns are not re-evaluated when the underlying columns are unavailable. (Bug #36515172)

  • Replication: When running GTID-based replication with relay_log_space_limit enabled, a restart of the auto positioning protocol sometimes resulted in an infinite loop, leading to a deadlock in replication. This was because relay_log_space_limit was not honoured, not only for transactions whose size exceed this limit, but when the replica could not purge previous logs as well.

    To fix this issue, we make the following changes:

    • The receiver respects relay_log_space_limit as set by the user, unless a transaction received by the receiver cannot fit into the purged relay log. Before queueing the received transaction, receiver now checks whether scheduling a full transaction is possible. If not, the receiver performs the following actions:

      • Sets the flag indicating that receiver is waiting

      • Rotates the relay log

      • Waits until it is notified that relay log purge was executed and that the applier has purged all available relay logs; after this, the receiver may queue a transaction without checking the limit again

    • Before moving to the next file, the coordinator checks whether the receiver is waiting for available relay log space. If so, the coordinator forcibly purges the applied logs, including the current relay log file. To purge the current relay log file safely, the coordinator must do the following:

      • Synchronize all of its workers before moving to the next file

      • Forcibly update group positions, which is necessary to allow current purging of the relay log

      • Update the variable read by the receiver which contains relay log filename to which applier was moved

      These operations are allowed because we know that receiver waits at a transaction boundary and rotates the relay log before waiting.

    (Bug #36507020)

  • Replication: Worker jobs now contain information about the relay log file which initiated the transaction, instead of using the default defined by relay_log. (Bug #36395631)

  • Replication: Handling an incident while transactions were being committed to the binary log caused MySQL to wait indefinitely. (Bug #35671897)

  • Group Replication: Removed a memory leak from /xcom/gcs_xcom_networking.cc. (Bug #36532199)

  • Group Replication: Under certain circumstances, if a primary's host experienced network inactivity of 20 seconds or more, the secondaries could stop unexpectedly. (Bug #36306144)

  • Group Replication: Under certain circumstances, if garbage collection occurred just before a relay log rotation, it could cause the applier to stop applying new transactions on the secondary members.

    This was caused by garbage collection incrementing the relay log's last_committed and sequence_number, creating a gap in the recorded sequence_number after the log rotation. The applier was unaffected if the gap occurred anywhere else in the relay log.

    As of this release, only last_committed is updated during garbage collection. (Bug #36280130, Bug #36446250)

  • JSON: Added missing checks for error handling to NULLIF(), COALESCE(), and the shift (>>) operator. (Bug #113668, Bug #35513196, Bug #36198403)

    References: See also: Bug #31358416.

  • MySQL NDB ClusterJ: Running the ClusterJ test suite resulted in an error message saying a number of threads did not exist. That was due to some wrong handling of threads and connections, which was corrected by this patch. (Bug #36086735)

  • Averages of certain numbers were not always computed correctly. (Bug #36563773)

  • The following files in strings contained incorrect license information:

    • mb_wc.h

    • ctype-uca.cc

    • ctype-ucs2.cc

    • ctype-utf8.cc

    • dtoa.cc

    • strxmov.cc

    • strxnmov.cc

    (Bug #36506181)

  • In certain unusual cases, the UpdateXML() function did not process all of its arguments correctly. (Bug #36479091)

  • Explaining a query which used FORCE INDEX on a spatial index containing a column with SRID attributes led to an unplanned exit. (Bug #36418426)

  • When incrementing the reference count for an expression, underlying expressions within this expression are not looked at. While removing an expression, after decrementing the reference count, even the underlying expressions were examined, which led to unintentional deletion of the underlying expressions. This issue manifested in Item_ref::real_item() as well as in an assert in sql/item.h. We fix this by not looking at the underlying expression unless the current expression contains the only remaining reference. (Bug #36204344, Bug #36356279)

  • Under certain conditions, EXPLAIN FORMAT=JSON FOR CONNECTION sometimes led to an unplanned exit. (Bug #36189820)

  • Under certain conditions, a race condition could result in the amount of RAM used by TABLE_HANDLES increasing to a maximum of 9GB. (Bug #36170903)

  • Some CREATE USER statements were not handled correctly. (Bug #36022885)

  • For a SELECT with ORDER BY and LIMIT, the optimizer first chose a full table scan with a very expensive cost, then performed another check and used the perform_order_index type of path, but this was not reflected by the cost in the optimizer plan. (Bug #35930969)

  • Client connections were not alway terminated correctly during shutdown. (Bug #35854919)

  • All internal ACL bitmask variables are now explicitly 32 bits (uint32_t). (Bug #35507223)

  • It was not possible to add a functional index on FIND_IN_SET(). (Bug #35352161)

  • Running two concurrent OPTIMIZE TABLE statements on the same table with fulltext indexes and innodb_optimize_fulltext_only enabled sometimes caused the server to exit. (Bug #34929814)

  • Removed a memory leak observed while running authentication_kerberos under Valgrind. (Bug #34482788, Bug #36570929)

  • The gen_range() function as implemented by the (deprecated) data masking plugin did not always return the correct result.

    This issue affected the data masking plugin only, and did not affect the data masking component which supersedes it. (Bug #34163992)

  • Fixed an erroneous comment in include/my_command.h.

    Our thanks to Sho Nakazono for the contribution. (Bug #114507, Bug #36455468)

  • It was possible for a deterministic stored function to return an incorrect result when the function used JOIN ON inside the return statement. If the query needed to be reprepared due to a table metadata caused by, for example, FLUSH TABLES between two executions, the ON clause was sometimes lost. (Bug #114235, Bug #36379879)

  • The PROCESSLIST_INFO column of THREADS was not updated when executing a prepared statement.

    Thanks to Daniel Lenski and Amazon for the contribution. (Bug #104121, Bug #33057164)