Documentation Home
MySQL 8.0 Release Notes
Related Documentation
MySQL 8.0 Reference Manual
Download these Release Notes
PDF (US Ltr) - 4.2Mb
PDF (A4) - 4.3Mb
MySQL 8.0 Release Notes  /  Changes in MySQL 8.0.4 (2018-01-23, Release Candidate)

Changes in MySQL 8.0.4 (2018-01-23, Release Candidate)

For general information about upgrades, downgrades, platform support, etc., please visit https://dev.mysql.com/doc/relnotes/mysql/8.0/en/.

Note

This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward. (Making a backup before the upgrade is a prudent precaution in any case.)

Beginning with MySQL 8.0.4, macOS 10.13 is a supported platform.

Compilation Notes

  • Linux: Binary packages on Linux platforms now are built using GCC 6. The optimization level has changed from -O3 to -O2. (WL #10343)

  • macOS; Microsoft Windows: For compiling MySQL from source, the -DWITH_SSL=system CMake option now works on Windows and macOS. (Bug #26907731, Bug #87938)

  • On platforms for which the GNU gold linker is used, removal of unused functions is now enabled, reducing the size of binaries. (Bug #26612067, Bug #87372)

  • #include directives in source files were rewritten and reorganized to be unambiguous. (Bug #26597243, Bug #87358, Bug #26897738)

  • The BUILD directory containing compilation scripts is no longer maintained and has been removed from MySQL source trees. (Bug #26576219, Bug #87323)

  • The minimum version of the Boost library for server builds is now 1.65.0. (Bug #26574924, Bug #87317)

  • MySQL can now be linked against OpenSSL 1.1 on Unix and Unix-like systems. (Bug #25094892, Bug #83814)

  • Work was done to clean up the source code base, including: Removing unneeded CMake checks; removing unused macros from source files; reorganizing header files to reduce the number of dependencies and make them more modular, removing function declarations without definitions, replacing locally written functions with equivalent functions from industry-standard libraries.

Component Notes

  • The validate_password plugin has been reimplemented to use the component infrastructure. To install and uninstall the validate_password component, use these statements: 

    INSTALL COMPONENT 'file://component_validate_password';
UNINSTALL COMPONENT 'file://component_validate_password';

    INSTALL PLUGIN and UNINSTALL PLUGIN still work to install and uninstall the validate_password plugin as before, but generate warnings. The plugin form of validate_password is deprecated and will be removed in a future MySQL version. MySQL installations that use the plugin should transition to the component instead. See Transitioning to the Password Validation Component.

    A usage difference between the component and plugin implementations of validate_password is that, whereas the plugin exposes system and status variables with names that begin with validate_password_, the component uses the convention of exposing variables with names that begin with the component name and a period. For example, the plugin exposes the validate_password_policy system variable and validate_password_dictionary_file_words_count status variable, whereas the corresponding variables exposed by the component are validate_password.policy and validate_password.dictionary_file_words_count. The plugin variables, like the plugin itself, are deprecated and will be removed in a future MySQL version. (WL #6667)

Configuration Notes

  • Replication: When calculating the binary log expiration period, any value that you specify for the deprecated expire_logs_days system variable is now ignored if binlog_expire_logs_seconds is set, and only the value of binlog_expire_logs_seconds is used. Previously, the effects of binlog_expire_logs_seconds and expire_logs_days were cumulative.

    If you set a value for both system variables at startup, a warning message is issued stating that the value of expire_logs_days is ignored. You cannot set or change the value of one option dynamically while the other is set, and an error message is issued in this situation.

    The default binary log expiration period of 30 days (as changed in MySQL 8.0.2) applies if neither binlog_expire_logs_seconds nor expire_logs_days has a value set at startup. If a value for either binlog_expire_logs_seconds or expire_logs_days is set at startup, this value overrides the default binary log expiration period. To disable automatic purging of the binary log, you must set both binlog_expire_logs_seconds and expire_logs_days explicitly to 0 at startup. (Bug #26274274, Bug #86698)

  • For RHEL, SLES, and Fedora RPMs, the default plugin directory for debug builds has been changed from /usr/lib64/mysql/plugin to /usr/lib64/mysql/plugin/debug. (Bug #27072155, Bug #88363)

  • The new WITH_LZMA and WITH_RE2 CMake options control whether to compile with the bundled or system LZMA and RE2 libraries.

  • The table_open_cache system variable default variable has been increased from 2000 to 4000. This additionally changes the default for the autosized table_definition_cache system variable from 1400 to 2000. (WL #9703)

  • The optimizer_trace_max_mem_size system variable default value was changed from 16KB to 1MB to lessen the likelihood of optimizer trace truncation. (WL #11345)

  • The log_error_verbosity system variable default value was changed from 3 (error, warning, and information messages) to 2 (error and warning messages) to make mysqld error logging less verbose by default. (WL #11143)

Deprecation and Removal Notes

  • InnoDB: The innodb_undo_tablespaces configuration option is deprecated and will be removed in a future MySQL version. (WL #10473)

  • Replication: The group_replication_primary_member status variable has been deprecated and will be removed in a future MySQL version. (WL #10958)

  • Replication: The group_replication_allow_local_disjoint_gtids_join system variable has been removed. (WL #11139)

  • When the libmysqld embedded server library was removed in MySQL 8.0.1, the following mysql_options() options used only for libmysqld were not removed. They have now been removed. 

    MYSQL_OPT_GUESS_CONNECTION
MYSQL_OPT_USE_EMBEDDED_CONNECTION
MYSQL_OPT_USE_REMOTE_CONNECTION
MYSQL_SET_CLIENT_IP

    (Bug #26712418)

  • mysqlpump no longer includes the SQL_NO_CACHE modifier in statements because that modifier is now deprecated and results in deprecation warnings. (Bug #26694675)

  • Generated columns no longer permit deprecated functions in the generation expression, to avoid problems when MySQL is upgraded to a version in which the deprecated functions have been removed. (Bug #26279884, Bug #86712)

  • The Performance Schema setup_timers table has been removed, as has the TICK row in the performance_timers table. (Bug #18296337, WL #10985, WL #10986)

SQL Function and Operator Notes

  • Incompatible Change: Previously, MySQL used the Henry Spencer regular expression library to support regular expression operators (REGEXP, RLIKE). Regular expression support has been reimplemented using International Components for Unicode (ICU), which provides full Unicode support and is multibyte safe. The REGEXP_LIKE() function performs regular expression matching in the manner of the REGEXP and RLIKE operators, which now are synonyms for that function. In addition, the REGEXP_INSTR(), REGEXP_REPLACE(), and REGEXP_SUBSTR() functions are available to find match positions and perform substring substitution and extraction, respectively. The regexp_stack_limit and regexp_time_limit system variables provide control over resource consumption by the match engine.

    MySQL source distributions bundle the ICU library, and the WITH_ICU CMake option controls whether to compile with the bundled or system ICU library. The ICU_VERSION() function returns the ICU library version.

    For more information, see Regular Expressions. For information about ways in which applications that use regular expressions may be affected by the implementation change, see Regular Expression Compatibility Considerations. (WL #8987)

  • Two new SQL functions are available to provide digest information about SQL statements. Given an SQL statement as a string, STATEMENT_DIGEST() returns the statement digest hash value, and STATEMENT_DIGEST_TEXT() returns the normalized statement digest. See Encryption and Compression Functions. (WL #9637)

InnoDB Notes

  • The restriction enacted in MySQL 8.0.3 against renaming of columns in a parent foreign key has been lifted. (Bug #26659110, Bug #87490, Bug #25722221)

    References: See also: Bug #26334071.

Installation Notes

  • For platforms that use systemd (see Managing MySQL Server with systemd), the data directory is initialized if empty at server startup. This might be a problem if the data directory is a remote mount that has temporarily disappeared: The mount point would appear to be an empty data directory, which then would be initialized as a new data directory. It is now possible to suppress this automatic initialization behavior. Specify the following line in the /etc/sysconfig/mysql file (create the file if it does not exist): 

    NO_INIT=true

    (Bug #26595288, Bug #87287)

Keyring Notes

  • MySQL now supports key migration between underlying keyring keystores, permitting DBAs to switch a MySQL installation from one keyring plugin to another. See Migrating Keys Between Keyring Keystores. (WL #9769)

Logging Notes

  • A new error log filter component, log_filter_dragnet, enables control over events written to the error log, based on user-defined rules specified as the value of the dragnet.log_error_filter_rules system variable. This new filtering capability is more flexible than is achievable using the built-in log_filter_internal filter component and log_error_verbosity system variable. For more information, see Types of Error Log Filtering. (WL #9651)

  • Messages written to the error log by the log_sink_internal log sink component now contain an error-ID indicator. This ID has a format of [error_id]. It follows the severity indicator and precedes the message text. For more information, see Error Log Output Format. (WL #11009)

  • When the log_error_verbosity system variable for error logging is set to filter out warning and information messages, selected important messages about non-error situations are now printed to error logs as system messages. These messages were previously handled and labeled as errors so that they were logged when log_error_verbosity=1 was set. The labeling function has now been decoupled from the handling function for these messages, so that the messages can be given an appropriate label.

    System messages now have the label “System” in the MySQL error log. Other log sinks that support custom labels might also use this convention. In logs that do not support custom labels, system messages are printed with the label used for the information level of severity. However, they are included even if the log_error_verbosity setting normally excludes messages at this level.

    If your system has additional configuration to discard messages labeled as information level, or to redirect them to a different destination from messages labeled as errors, system messages do not override this behavior. If the log sink involved does not use the “System” label, system messages are now discarded or redirected along with other messages labeled as information level.

    The messages that are now printed with the “System” label where supported include startup and shutdown messages, and some significant changes to settings, as follows:

    (WL #10942)

Packaging Notes

  • All MySQL binary distributions now are linked against OpenSSL, including Community distributions, which previously were linked against yaSSL. In addition, OpenSSL is linked dynamically rather than statically, which enables substitution of alternative SSL libraries for use with MySQL if desired. For some platforms, binary distributions bundle OpenSSL libraries to ensure library availability:

    • Windows: Distributions bundle libeay32.dll and ssleay32.dll, which are installed in the same directory as MySQL binaries. Other libraries can be used by replacing those library files with alternatives, or by using some other library-selection method supported on Windows. (See https://msdn.microsoft.com/en-us/library/7d83bc18.aspx.)

    • macOS: Distributions bundle libssl.dylib and libcrypto.dylib. MySQL binaries are linked to expect the libraries in the same directory, and symbolic links there point to the actual library locations.

    • Linux (for generic compressed tar file distributions only): Distributions bundle libssl.so and libcrypt.so,which are installed in the same directory as the libmysqlclient.so client library.

    (Bug #26272084, Bug #26134893, Bug #26927607, Bug #87996, WL #10524)

Performance Schema Notes

  • The Performance Schema now uses SHA-256 hashes for statement digests rather than MD5 hashes. To accommodate the increased storage required for SHA-256 values, DIGEST columns in Performance Schema tables are widened from VARCHAR(32) to VARCHAR(64). (Bug #26727443)

Security Notes

  • Incompatible Change: Passwords are now restricted to a maximum of 256 characters for the caching_sha2_password and sha256_password authentication plugins, and for the PASSWORD() function when old_passwords=2. Also, the number of password hashing rounds is capped to limit CPU time used. (Bug #27099029, Bug #27194270)

  • Incompatible Change: The caching_sha2_password and sha256_password authentication plugins provide more secure password encryption than the mysql_native_password plugin, and caching_sha2_password provides better performance than sha256_password. Due to these superior security and performance characteristics of caching_sha2_password, it is now the preferred authentication plugin, and is also the default authentication plugin rather than mysql_native_password. This change affects both the server and the libmysqlclient client library:

    • For the server, the default value of the default_authentication_plugin system variable changes from mysql_native_password to caching_sha2_password.

    • The libmysqlclient library treats caching_sha2_password as the default authentication plugin rather than mysql_native_password.

    This change has the following implications:

    • The change affects only the authentication plugin used for creating new MySQL accounts. For accounts already existing in an upgraded installation, their authentication plugin remains unchanged.

    • Clients that use an account that authenticates with caching_sha2_password must use either a secure connection (made using TCP using TLS/SSL credentials, a Unix socket file, or shared memory), or an unencrypted connection that supports password exchange using an RSA key pair. This security requirement does not apply to mysql_native_passsword, so the switch to caching_sha2_password may require additional configuration (see Caching SHA-2 Pluggable Authentication). However, client connections in MySQL 8.0 prefer use of TLS/SSL by default, so clients that already conform to that preference may need no additional configuration.

    • Because caching_sha2_password is also now the default authentication plugin in the libmysqlclient client library, authentication requires an extra round trip in the client/server protocol for connections from MySQL 8.0 clients to accounts that use mysql_native_password (the previous default authentication plugin), unless the client program is invoked with a --default-auth=mysql_native_password option.

    • Incompatibility: Clients and connectors that have not been updated to know about caching_sha2_password cannot connect to accounts that authenticate with caching_sha2_password because they do not recognize this plugin as valid. To work around this issue, relink clients against libmysqlclient from MySQL 8.0.4 or higher, or obtain an updated connector that recognizes caching_sha2_password.

    • Incompatibility: Clients and connectors that have not been updated to know about caching_sha2_password may have trouble connecting to a MySQL 8.0 server configured with caching_sha2_password as the default authentication plugin, even to use accounts that do not authenticate with caching_sha2_password. This issue occurs because the server specifies the name of its default authentication plugin to clients. If a client or connector is based on a client/server protocol implementation that does not gracefully handle an unrecognized default authentication plugin, it may fail with an error.

    For more information about the more prominent role of caching_sha2_password, including discussion of potential compatibility issues and solutions, see caching_sha2_password as the Preferred Authentication Plugin.

    Additionally, replication slaves are now able to connect to masters using RSA key pair-based password exchange. This RSA capability applies for accounts that authenticate with the caching_sha2_password or sha256_password authentication plugin. (Previously, slaves could authenticate with those plugins, but required a secure connection and could not use RSA password exchange.) The following changes enable use of this new slave RSA capability:

    More programs now support a --server-public-key-path option to enable specifying a client-side file containing the public key for RSA key pair-based password exchange, for accounts that authenticate with the caching_sha2_password or sha256_password authentication plugin: mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlpump, mysqlshow, mysqlslap, mysql_upgrade. Previously, only mysql and mysqltest supported --server-public-key-path. The --server-public-key-path option is an alternative to --get-server-public-key, and may be used when a client-side file is available that contains a copy of the RSA public key required by the server, rather than sending a request for the public key to the server.

    The new mysql_reset_server_public_key() C API function clears any cached copy of the server RSA public key from the client library. See mysql_reset_server_public_key().

    The new caching_sha2_password_auto_generate_rsa_keys system variable enables automatic RSA private/public key-pair file generation, similar to the sha256_password_auto_generate_rsa_keys system variable. See Automatic SSL and RSA File Generation.

    The new Caching_sha2_password_rsa_public_key status variable exposes the public key used by the caching_sha2_password authentication plugin for RSA key pair-based password exchange. (Bug #26751594, WL #11057)

  • The linked OpenSSL library for MySQL Server has been updated to version 1.0.2n. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. (Bug #27212666, Bug #27236394)

  • Certificates automatically generated by mysqld and mysql_ssl_rsa_setup now use X509 v3 rather than v1. (Bug #26521654)

Server Administration

  • A new RESTART SQL statement is available that enables restarting a MySQL server instance from within a client session. This feature is available for platforms on which a monitoring process is able to detect a server shutdown performed for restart purposes: Windows (mysqld started as a Windows service or standalone), and Unix and Unix-like systems that use systemd or mysqld_safe to manage mysqld. See RESTART Statement. (WL #9809)

Spatial Data Support

Test Suite Notes

  • Documentation for the MySQL Test Suite is now maintained in the MySQL source tree using Doxygen (see the MySQL Server Doxygen documentation, available at https://dev.mysql.com/doc/index-other.html.) The related Unix man pages that previously were produced from the old test suite manual are no longer updated and have gone out of date. Consequently, they are no longer included in MySQL distributions. (Bug #27021754)

  • The MySQL test suite now includes CRC32() tests. Thanks to Daniel Black for the patch. (Bug #26495791, Bug #87136)

  • mysqltest now accepts an optional retry argument for these commands: copy_file copy_files_wildcard, file_exists, move_file, remove_file, and remove_files_wildcard. Usage is as follows: 

    --file_operation file_name ... [retry]

    When the retry argument is specified, the command retries a failed operation the given number of times at one-second intervals. (Bug #24671890)

X Plugin Notes

  • X Plugin could incorrectly remove quotes from parameters that were passed to functions expecting JSON strings, causing an error. (Bug #26906519)

  • After an index was created on a collection, X Plugin would list the collection as a relational table, and no longer list it as a collection. (Bug #26906487)

  • X Protocol displayed the DATE type in the same way as the DATETIME type. The two data types are now treated differently. (Bug #26647488)

  • mysqlxtest did not display fractional seconds in DATETIME values correctly. (Bug #26638422)

  • X Plugin returned a column metadata field showing fractional digits for a JSON column, for which that information was irrelevant. The field is no longer returned. (Bug #26258481)

  • X Plugin handled user account lookup incorrectly if the IP address resolved to an empty host name. (Bug #26042786)

  • X Plugin can now be configured to abort any authenticated connections which are considered idle. The following system variables have been added:

    (WL #9267)

  • X Plugin now supports Caching SHA-2 Pluggable Authentication. To enable the support, issue: 

    INSTALL PLUGIN mysqlx_cache_cleaner SONAME 'mysqlx.so';

    This plugin maintains the cache and removes all entries for accounts that were modified. (WL #10992)

    References: See also: Bug #27213213, Bug #27042109.

Functionality Added or Changed

  • InnoDB: Obsoleted InnoDB system tables that are no longer required after upgrading to MySQL 8.0.3 or later are now dropped after a successful upgrade. (Bug #26757171)

  • InnoDB: Support was added to automatically upgrade data dictionary table definitions when starting the MySQL server after upgrading MySQL binaries to a new version. At startup, the data dictionary version of the server is compared to the version information stored in the data dictionary to determine if data dictionary tables should be upgraded. If an upgrade is necessary and supported, the server creates data dictionary tables with updated definitions, copies persisted metadata to the new tables, atomically replaces the old tables with the new ones, and reinitializes the data dictionary. If an upgrade is not necessary, startup continues without updating the data dictionary tables.

    The mysqld --no-dd-upgrade option can be used to prevent automatic upgrade of data dictionary tables at startup. (WL #9553)

  • InnoDB: Moving or restoring tablespace files to a new location while the server is offline is supported by the new --innodb-directories option, which defines directories to scan at startup for tablespace files. For more information, see Moving Tablespace Files While the Server is Offline.

    With the introduction of the --innodb-directories feature, the location of file-per-table and general tablespace files created with an absolute path or in a location outside of the data directory should be added to the innodb_directories argument value. Otherwise, InnoDB is not able to locate these files during recovery. To view tablespace file locations, query the INFORMATION_SCHEMA.FILES table: 

    mysql> SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES \G

    The CREATE TABLESPACE ... ADD DATAFILE statement now requires that a specified directory is known to InnoDB. Known directories include those implicitly and explicitly defined by the innodb_directories option.

    innodb_directories replaces innodb_scan_directories, which has been removed. (WL #8619)

  • InnoDB: InnoDB now supports partial update of large object (LOB) data stored in external fields outside of clustered index pages, including JSON documents updated using JSON_SET() and JSON_REPLACE(). Previously, LOB values could only be read or modified in full, and updates of JSON column values were done by completely removing the previous document and writing the new one in its place.

    Partial update uses an internal LOB index, or ZLOB index in the case of compressed LOB data, which is created and stored in one or more LOB pages when a row containing LOB data is inserted or updated. Thus, partial fetch and update of LOB data is supported for newly inserted rows, but existing rows containing LOB data must be updated to add partial fetch and update support. The addition of LOB index data increases the storage space required by LOB values by a small percentage.

    This feature adds the following InnoDB page types for storing uncompressed and compressed LOB data:

    • FIL_PAGE_TYPE_LOB_INDEX

    • FIL_PAGE_TYPE_LOB_DATA

    • FIL_PAGE_TYPE_LOB_FIRST

    • FIL_PAGE_TYPE_ZLOB_FIRST

    • FIL_PAGE_TYPE_ZLOB_DATA

    • FIL_PAGE_TYPE_ZLOB_INDEX

    • FIL_PAGE_TYPE_ZLOB_FRAG

    • FIL_PAGE_TYPE_ZLOB_FRAG_ENTRY

    (WL #8960)

  • InnoDB: The storage engine private field of the mysql.tablespaces data dictionary table and page 0 of InnoDB tablespace files now store MySQL server version and tablespace version information. The MySQL server version is the version that created the tablespace, the version into which the tablespace was imported, or the version of the last major MySQL upgrade. The tablespace version tracks tablespace format changes. SERVER_VERSION and SPACE_VERSION fields were added to the INFORMATION_SCHEMA.INNODB_TABLESPACES table to provide access to this data. (WL #5989, WL #11063)

  • Group Replication: Host names can now be specified as part of a whitelist for group replication connections, using the group_replication_ip_whitelist system variable. Host names support CIDR notation. Host names that resolve to IPv6 addresses are not supported.

    For host names, name resolution takes place only when a connection request is made by another server. A host name that cannot be resolved is not considered for whitelist validation, and a warning message is written to the error log. Forward-confirmed reverse DNS (FCrDNS) verification is carried out for resolved host names.

    Warning

    Host names are inherently less secure than IP addresses in a whitelist. FCrDNS verification provides a good level of protection, but can be compromised by certain types of attack. Specify host names in your whitelist only when strictly necessary, and ensure that all components used for name resolution, such as DNS servers, are maintained under your control. You can also implement name resolution locally using the hosts file, to avoid the use of external components.

    (WL #10803, WL #11298)

  • JSON: Added the JSON_TABLE() function, which accepts JSON data and returns it as a relational table whose columns are as specified. This virtual table can be accessed using standard SQL mechanisms

    This function has the syntax JSON_TABLE(expr, path COLUMNS column_list) [AS] alias), where expr is an expression that returns JSON data, path is a JSON path applied to the source, and column_list is a list of column definitions. Columns can be of the types FOR ORDINAL, PATH, EXISTS PATH, and NESTED PATH or NESTED, as described in the following list:

    • FOR ORDINAL: The column is a counter, similar to an AUTO_INCREMENT column.

    • PATH: The column holds a scalar value using the specified JSON path. ON ERROR and ON EMPTY options are supported for handling illegal values (such as nonscalars) and empty values, respectively.

    • EXISTS PATH: The column value is 1 if a match exists for the specified JSON path, and 0 otherwise.

    • NESTED PATH: Nested objects or arrays in JSON data found in the given JSON path are flattened into a single row along with the JSON values from the parent object or array. The PATH keyword is optional.

    Two simple examples are shown here: 

    mysql> SELECT *
    -> FROM
    ->   JSON_TABLE(
    ->     '[1, 3, 5, 7, 9]',
    ->     "$[*]" COLUMNS(rowid FOR ORDINALITY, col VARCHAR(50) PATH "$")
    ->   ) AS t1;
+-------+------+
| rowid | col  |
+-------+------+
|     1 | 1    |
|     2 | 3    |
|     3 | 5    |
|     4 | 7    |
|     5 | 9    |
+-------+------+

mysql> SET @j = '[{"a": [{"x":"3"},{"y":"2"}]},
    '>   {"b": [{"x":"1"},{"y":"1"}]},
    '>   {"a": [{"x":"2"},{"y":"3"}]}]';

mysql> SELECT *
    -> FROM  JSON_TABLE(
    ->         @j,
    ->         "$[*]"  COLUMNS(
    ->                   rowid FOR ORDINALITY,
    ->
    ->                   xa INT EXISTS PATH "$.a",
    ->                   xb INT EXISTS PATH "$.b",
    ->
    ->                   ja JSON PATH "$.a",
    ->                   jb JSON PATH "$.b"
    ->                 )
    ->       ) AS jts;
+-------+------+------+--------------------------+--------------------------+
| rowid | xa   | xb   | ja                       | jb                       |
+-------+------+------+--------------------------+--------------------------+
|     1 |    1 |    0 | [{"x": "3"}, {"y": "2"}] | NULL                     |
|     2 |    0 |    1 | NULL                     | [{"x": "1"}, {"y": "1"}] |
|     3 |    1 |    0 | [{"x": "2"}, {"y": "3"}] | NULL                     |
+-------+------+------+--------------------------+--------------------------+

    The JSON source expression can be any expression that yields a valid JSON document, including a JSON literal, a table column, or a function call that returns JSON such as JSON_EXTRACT(t1, data, '$.post.comments'). For complete syntax and other information about this function, see JSON Table Functions. (WL #8867)

  • The -DWITH_ASAN_SCOPE CMake option enables the AddressSanitizer -fsanitize-address-use-after-scope Clang flag for use-after-scope detection. The default is off. To use this option, -DWITH_ASAN must also be enabled. (Bug #27095089)

  • Handling of empty JSON documents has been made more robust. (Bug #26787468, Bug #87734)

  • MySQL 8.0.3 imposed a restriction against ALTER TABLE RENAME on tables in a foreign key relationship if a LOCK TABLES was active. This restriction has been lifted. (Bug #26647340, Bug #87467)

  • If the server PID file is configured to be created in a world-writable location, the server now issues a warning suggesting use of a more secure location. (Bug #26585560)

  • For constructs using _charset character set introducers (for example, _utf8mb4 'abc'), lookup performance was improved for mapping the introducer onto the proper character set. (Bug #25680866, Bug #85331)

Bugs Fixed

  • Important Change: The following changes are made to the PERIOD_ADD() and PERIOD_DIFF() functions:

    • A period value used with one of these functions may not be negative.

    • The month part of a period value may not be equal to 0.

    A period value used with one of these functions for which at least one of these conditions is true now causes the function to fail with an error. (Bug #27004699, Bug #27004729)

  • Important Change: The LEAST() and GREATEST() functions no longer attempt to infer a context for their arguments from expressions in which they are used. For example, LEAST('11', '45', '2') returns '11', but LEAST('11', '45', '2') + 0 treated the function arguments as integers rather than as strings, and returned 2. Now these functions always evaluate their arguments strictly according to type, and any data type coercion due to their inclusion in an expression is performed only on the result returned by the function. This means that the expression LEAST('11', '45', '2') + 0 now evaluates to '11' + 0, and thus to the integer value 11.

    This change has been made due to the following considerations:

    • Rules for deriving the context were not always clear or consistent.

    • The results of these functions when used in expressions were not consistent with the results of COALESCE(), or of a UNION query.

    Applications that use these functions within expressions should be checked to make sure that they do not depend on the previous behavior, and updated if they do so. (Bug #83895, Bug #25123839)

  • InnoDB: Concurrent XA transactions that ran successfully to the XA prepare stage on the master conflicted when replayed on the slave, resulting in a lock wait timeout in the applier thread. The conflict was due to the GAP lock range which differed when the transactions were replayed serially on the slave. To prevent this type of conflict, GAP locks taken by XA transactions in READ COMMITTED isolation level are now released (and no longer inherited) when XA transactions reach the prepare stage. (Bug #27189701, Bug #25866046)

  • InnoDB: An ALTER TABLE operation that added a foreign key constraint referencing a table with generated virtual columns raised an assertion. (Bug #27189701)

  • InnoDB: A DROP DATABASE operation raised an assertion due to a missing general tablespace data file. (Bug #27151163)

  • InnoDB: On Windows, an operation that altered a table partition raised an assertion. The table name was not parsed correctly. (Bug #27075816)

  • InnoDB: A TRUNCATE TABLE operation on a temporary table raised an assertion. (Bug #27073280)

  • InnoDB: A call to a recovery-related function during the post-DDL phase of a DDL operation raised an assertion. (Bug #27041487, Bug #88263)

  • InnoDB: Adding a spatial index that referenced a column with an SRID attribute returned an error. (Bug #27021029)

  • InnoDB: A table with a 64-character foreign key name caused an upgrade failure. Foreign key names up to 64 characters in length should be permitted. (Bug #27014308, Bug #88196)

  • InnoDB: The InnoDB recovery process failed with a tablespace size error for a compressed table that was upgraded from MySQL 5.7 to MySQL 8.0.

    The tablespace file for a compressed table is now created using the physical page size instead of the InnoDB page size, which makes the initial size of a tablespace file for an empty compressed table smaller than in previous MySQL releases. (Bug #27014083, Bug #88195)

  • InnoDB: Unnecessary tablespace fetch and cache update operations caused a server startup delay. (Bug #26995951)

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

  • InnoDB: An orphan .frm file caused an upgrade failure, and subsequent upgrade attempts were unsuccessful due to a full-text search auxiliary table that was renamed during the first upgrade attempt. (Bug #26995951)

  • InnoDB: Workarounds introduced to address conflicting serialized dictionary information (SDI) inserts during concurrent CREATE TABLE operations were removed. (Bug #26995534)

    References: See also: Bug #26539665.

  • InnoDB: A “no space left on device” error reported an invalid error message. (Bug #26960345)

  • InnoDB: During a fast shutdown, InnoDB attempted to write dynamic metadata to the data dictionary after files were closed, resulting in an initialization failure due pending I/O on the data dictionary tablespace. (Bug #26950659)

  • InnoDB: A stack overflow error was encountered on startup after upgrading to MySQL 8.0.4 due to repeated attempts to load an evicted InnoDB system table. (Bug #26945437, Bug #88042)

  • InnoDB: Importing a compressed table raised an assertion. The operation used the clustered index of the table instead of the serialized dictionary information (SDI) index to transform SDI pages. (Bug #26938297)

  • InnoDB: In debug builds, failed temporary table creation during a REPLACE operation raised an invalid assertion. (Bug #26919378, Bug #26958868)

  • InnoDB: DROP DATABASE failed if database tables were created in a general tablespace. General tablespace flags were registered incorrectly causing the serialized dictionary information (SDI) operation to fail. (Bug #26834496)

  • InnoDB: With binary logging enabled, an ALTER TABLESPACE ... RENAME operation failed with a “cannot find space” error. (Bug #26832347)

  • InnoDB: An operation that failed to add an index raised an invalid adaptive hash index assertion. (Bug #26788968)

  • InnoDB: A valid table row type value read from the data dictionary raised an invalid assertion. (Bug #26773152)

  • InnoDB: Starting an upgrade with innodb_force_recovery=5 initialized InnoDB background threads but did not exit the threads gracefully when an error was encountered. Upgrading with a nonzero innodb_force_recovery setting is no longer permitted. (Bug #26766632)

  • InnoDB: A failed CREATE TEMPORARY TABLE statement left an entry in INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO. The in-memory table object was not freed. (Bug #26765438)

  • InnoDB: InnoDB looked up the name of a virtual column in the wrong dict_table_t array when attempting to locate a qualifying index for a foreign key. (Bug #26764604)

  • InnoDB: Attachable read-write transactions that update the table_stats and index_stats data dictionary tables attempted to update the same row, causing a deadlock. (Bug #26762517)

  • InnoDB: During recovery, the tablespace name in an in-memory tablepace object was defined using the file name character set instead of table name character set, resulting in a “missing tablespace” error. (Bug #26761960)

  • InnoDB: Bootstrap code did not reserve the first 1024 table IDs for data dictionary tables. (Bug #26757227)

  • InnoDB: Multiple updates from different clients on a partitioned table caused an unexpected lock wait timeout due to an incorrectly set lock type. (Bug #26731025, Bug #87619)

  • InnoDB: An asynchronous rollback thread that attempted to acquire a metadata lock was interrupted, but the resulting error was not returned to the server. This issue was addressed by removing the metadata lock acquisition, which was not necessary for asynchronous rollback.

    Only in-memory tables were checked when opening tables for undo processing. The data dictionary is now checked as well, in case tables are not present in memory. (Bug #26678883)

  • InnoDB: An assertion was raised when attempting to open a full-text auxiliary table with a name that was longer than expected. (Bug #26649020)

  • InnoDB: Data dictionary table open functions did not properly handle table and schema name character set conversion, resulting in an error during recovery. (Bug #26640776)

  • InnoDB: A transaction end_stmt() function was not called in some ALTER TABLE ... PARTITION scenarios, resulting in a timeout. (Bug #26629790, Bug #25886814)

  • InnoDB: Acquiring a metadata lock on the serialized diction information (SDI) table during the commit phase of a DDL operation would fail due to a lock wait timeout or halting of the query. (Bug #26628126)

  • InnoDB: Redo logs for dynamic metadata updates were not considered when checking redo log margin. Also, in read-only mode, the innodb_dynamic_metadata data dictionary table was opened unnecessarily for writing of metadata from the redo log. (Bug #26589535)

  • InnoDB: An unexpected error occurred after a failed attempt to install the memcached plugin. (Bug #26588738)

  • InnoDB: The state of a buffer pool page was altered by another thread while a buffer pool resize operation was in progress. (Bug #26588537)

  • InnoDB: Debug functions that assert for conflicting locks did not account for transaction locks that are to be committed or rolled back. (Bug #26562371)

  • InnoDB: Variance-Aware Transaction Scheduling (VATS) functionality that updates the age of waiting record locks failed to ignore table locks, causing an assertion failure. (Bug #26538702)

  • InnoDB: A DDL operation that created or modified a table partition unintentionally altered the row format of other partitions, resulting in a row format mismatch. (Bug #26535746)

  • InnoDB: An ALTER TABLE operation caused the server to halt. (Bug #26492721)

  • InnoDB: The innodb_table_stats data dictionary table was not updated with new partition names when renaming a partitioned table. (Bug #26390658, Bug #86927)

  • InnoDB: Due to a regression introduced in MySQL 8.0.0, the innodb_change_buffering configuration option could not be set dynamically. (Bug #26389442)

  • InnoDB: The online log for a freed index was accessed while rolling back a concurrent UPDATE statement during an online DDL operation. (Bug #26334475)

  • InnoDB: A REPLACE operation on a table with a secondary index on the prefix of a virtual column raised an assertion. (Bug #26330279)

  • InnoDB: Setting tmpdir to the root of a drive caused “Invalid (old?) table or database name” error messages to be printed to the error log. (Bug #26299984, Bug #86737)

  • InnoDB: A race condition occurred during an INFORMATION_SCHEMA query when attempting to check the transaction state without acquiring a transaction mutex. (Bug #26299705)

  • InnoDB: A FLUSH TABLES operation failed to drop an aborted index. While removing the table from the cache, the clustered index was dropped prior to checking for the aborted index. (Bug #26256456, Bug #86607)

  • InnoDB: For InnoDB tables, CREATE TABLE ... LIKE did not respect the innodb_file_per_table system variable setting, and SHOW CREATE TABLE displayed a TABLESPACE clause even though the user specified no explicit tablespace during table creation. (Bug #26199233, Bug #86589)

  • InnoDB: An iterative approach to processing foreign cascade operations resulted in excessive memory use. (Bug #26191879, Bug #86573)

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

  • InnoDB: The lock acquisition sequence for a buffer pool eviction operation that evicts compressed pages was incorrect. (Bug #25972975)

  • InnoDB: Metadata locks were released while data dictionary objects were still in use. (Bug #25928984)

  • InnoDB: innochecksum returned a Valgrind error when run on InnoDB files with a 1K compressed page size. (Bug #25922124, Bug #85993)

  • InnoDB: A kill thread failed to close the socket of another thread that was executing a TRUNCATE TABLE operation, causing an assertion. (Bug #25887335, Bug #85925)

  • InnoDB: An INSERT operation on a table with a spatial index raised an assertion due to a failure that occurred during a lock conflict check. (Bug #25729649)

  • InnoDB: A debug sync point intended for user tables was activated for data dictionary tables. (Bug #25508568)

  • InnoDB: A server-side check was added to prevent a foreign key constraint from being placed on the base column of a generated stored column. (Bug #25339192)

  • InnoDB: Warnings that should only appear in debug builds of MySQL were printed to the error log when the length of the history list exceeded 2000000. (Bug #24296076, Bug #82213)

  • InnoDB: Attempting to reduce the buffer pool size to less than the buffer pool chunk size did not report a warning. (Bug #23590280)

  • InnoDB: A “wrong key column” error was added to address an unsupported index creation scenario. (Bug #22486025)

  • InnoDB: Full-text search on indexed columns that use a binary collation did not return case-sensitive matches. (Bug #21625016, Bug #78048)

  • Packaging: When trying to install MySQL Server on Fedora 27 using the MySQL Yum repository, installation failed due to a conflict with the native mariadb-connector-c-devel package. With this fix, the appropriate “obsoletes” have been added for that and other native packages. (Bug #26963839)

  • Partitioning: When creating a partitioned table using an implicit tablespace, the effect is to place each partition in its own tablespace, with no designated tablespace for the table as a whole. Since serialized dictionary information (SDI) was stored in all tablespaces used by a given table, the cost of storing it in a table with many tablespaces became prohibitive. This problem is solved by including only the tablespace for the first partition in the set of tablespaces used to store the SDI. (Bug #26762973)

    References: See also: Bug #26765252.

  • Partitioning: An assertion could be raised on CREATE VIEW on partitioned tables when the server tried to prune partitions of the underlying tables. (Bug #26659699)

  • Partitioning: When renaming a partitioned table, the table statistics were not updated with the new partition names. (Bug #86074, Bug #25953183)

  • Replication; JSON: For row-based replication, partial updates to JSON documents were not applied if the server variable binlog_row_value_options=PARTIAL_JSON (introduced in MySQL 8.0.3) was not specified on the replication slave, as well as on the master. Now, a replication slave applies partial updates to JSON documents whenever these are received from the master, whether or not the slave has binlog_row_value_options=PARTIAL_JSON in its own settings. (Bug #26762675)

  • Replication: The function set_unknow_error() in the Binlog_sender class has been renamed to set_unknown_error(). Thanks to Simon Mudd for the fix (and also for the typo fix in Bug 88149). (Bug #27149075, Bug #88559)

    References: See also: Bug #26996065, Bug #88149.

  • Replication: When you invoke mysqld with the --initialize or --initialize-insecure option to initialize the data directory, a warning message is no longer issued regarding the availability of the mysql.gtid_executed table, which should not be available at that stage. Also, the message formerly issued as a warning regarding the generation of a new UUID is now issued as a note, because the generation of a new UUID is normal in that situation. (Bug #27115183)

  • Replication: In MySQL 8.0.3, the default base name for the binary log files and index file was host_name-bin, using the name of the host machine. This default name was used if the --log-bin option was not supplied, and also if the --log-bin option was supplied with no string or with an empty string. From MySQL 8.0.4, if you do not supply the --log-bin option, MySQL now uses binlog as the default base name for the binary log files and index file. In releases before MySQL 8.0.3, there was no binary log with that configuration, so there is no incompatibility with existing binary logs at upgrade. However, for compatibility with existing binary logs from releases before MySQL 8.0.3, if you supply the --log-bin option with no string or with an empty string, the base name defaults to host_name-bin, using the name of the host machine.

    The warning messages that were previously issued at startup if you did not specify a binary log file name using the --log-bin option (ER_LOG_BIN_BETTER_WITH_NAME) and if you did not specify a server ID by setting the server_id system variable (ER_WARN_NO_SERVERID_SPECIFIED) are now issued as informational messages. A warning message is still issued if replication is attempted with a nonunique server ID. (Bug #27082922)

  • Replication: In the Gtid_log_event that precedes every GTID transaction in the binary log file, the transaction_length field used 8 bytes for transactions with 16777216 bytes or more, when it should have used the maximum permitted 9 bytes. (Bug #26993433)

  • Replication: The fix for Bug #22671846 was missing from MySQL version 8.0.3. (Bug #26985976)

  • Replication: The fix for Bug #26117735 (MySQL Bug #86288) could cause a debug assertion when running mysqlbinlog with the --read-from-remote-server option and the --rewrite-db option, depending on the database names specified in the rewrite rule. The issue has now been corrected. (Bug #26878022)

  • Replication: With MySQL compiled using yaSSL, and semisynchronous replication in use, a deadlock could be caused by incorrect handling of acknowledgement packets. Multiple acknowledgement packets can be read together by yaSSL, but the receiver thread for semisynchronous replication only handled the first acknowledgement packet seen after polling. Now, the receiver thread handles all acknowledgement packets that are present in the buffer. (Bug #26865538)

  • Replication: With semisynchronous replication in use, if RESET MASTER was issued while an active transaction was waiting for an acknowledgement from the slave, the count of waiting sessions in the Rpl_semi_sync_master_wait_sessions server status variable was incorrect after the wait was completed. (Bug #26748533)

  • Replication: The --log-slave-updates and --slave-preserve-commit-order options require binary logging. If you specify these options and also disable binary logging using the --skip-log-bin or --disable-log-bin option, a warning or error message is issued. The --skip-log-bin and --disable-log-bin options now disable the --log-slave-updates and --slave-preserve-commit-order options by default, so when those options are not specified, the warning or error message is not issued. (Bug #26666259)

  • Replication: XA ROLLBACK statements that failed because an incorrect transaction ID was given, could be recorded in the binary log with the correct transaction ID, and could therefore be actioned by replication slaves. A check is now made for the error situation before binary logging takes place, and failed XA ROLLBACK statements are not logged. (Bug #26618925, Bug #87393)

  • Replication: For the NDB storage engine, when the slave used hashing for searches of rows (which is included by default in the setting for the slave_rows_search_algorithms system variable from MySQL 8.0.2), the table used to store the row hashes was not cleaned up correctly after records were removed on the slave. The issue was caused by a variant error value returned by the NDB storage engine, which has now been corrected to the expected value. (Bug #26434966)

  • Replication: MySQL internal administration commands that update replication-specific repository tables, for example during a replication synchronization check using the mysqlrplsync utility, can now bypass read locks. This enables such commands to execute regardless of the settings for the read_only and super_read_only system variables and the autocommit mode. (Bug #26414532, Bug #86224)

  • Replication: The binary log function MYSQL_BIN_LOG::new_file_impl returned the error “Can't open file” (ER_CANT_OPEN_FILE) when it should have returned “Error writing file” (ER_ERROR_ON_WRITE). (Bug #26370868, Bug #86870)

  • Replication: When write sets are used for parallelization by a replication slave (as specified by the binlog_transaction_dependency_tracking system variable), the case and accent sensitivity of the database are now taken into account when generating the write set information. Write set information is generated when the transaction_write_set_extraction system variable is enabled. Previously, duplicate keys could be incorrectly identified as different, causing transactions to have incorrect dependencies and so potentially be executed in the wrong order. (Bug #26277771, Bug #86078)

  • Replication: The receiver thread for semisynchronous replication was not able to receive acknowledgements from slaves that used compression of the master/slave protocol (slave_compressed_protocol=ON). The receiver thread now handles compressed acknowledgements correctly. (Bug #26027024, Bug #86230)

  • Replication: The mysql_reset_connection() function now clears the write set session history. (Bug #25950554, Bug #86063)

  • Replication: On replication slaves, in the XA_STATE field in the Performance Schema table events_transactions_current, the state of XA transactions was incorrectly reported as COMMITTED instead of PREPARED after the XA PREPARE statement was applied on the slave. (Bug #25940184)

  • Replication: In a multi-source replication topology, a memory leak could occur on the slave when binlog_rows_query_log_events was enabled on the master, and a statement already applied from another channel was skipped on the slave. In this situation, the instance of the Rows_query log event stored on the slave was not being deleted. The log event instance is now cleaned up and the memory is freed. Thanks to Vlad Lesin for his contribution to the patch. (Bug #25695434, Bug #85371, Bug #85034)

  • Replication: Queries to the Performance Schema replication_applier_global_filters and replication_applier_filters tables, which show the global and channel-specific replication filters configured on a replication slave, have been optimized so that a view is generated only when the filters are changed. Previously, a view was generated for every row that was created. (Bug #25694140)

  • Replication: A memory leak was fixed in GTID-based replication. Memory was not being freed after the repository tables were updated for skipped or ignored events. (Bug #25656123, Bug #85251)

  • Replication: When a worker thread on a multithreaded slave failed to apply a transaction on which a later transaction depended, the coordinator thread could begin scheduling the dependent transaction before being notified of the issue. If a STOP SLAVE request was made during this situation, it caused an assertion to be raised in debug builds. (Bug #25585436)

  • Replication: With statement-based replication in use, if an UPDATE or DELETE statement was used inside an XA transaction ending with XA COMMIT ONE PHASE, and the statement did not affect any rows, a replication error occurred. An XA END statement was not written to the binary log, so slave servers identified the XA transaction as still being active at the time of the commit request. The required XA END statement is now written even if the transaction affected no rows. (Bug #24812958, Bug #83295)

  • Replication: Replication clients no longer enable LOCAL capability for LOAD DATA statements, because they do not use LOAD DATA LOCAL statements. (Bug #24763131)

  • Replication: The behavior of mixed-format replication (binlog_format=MIXED) has changed with regards to temporary tables. Previously, when mixed-format binary logging was in use, if a statement was logged by row and the session that executed the statement had any temporary tables, all subsequent statements were treated as unsafe and logged in row-based format until all temporary tables in use by that session were dropped. Also, on a replication slave with log_slave_updates enabled, row-based logging was incorrectly continued across all subsequent sessions for the duration of the connection, as reported in the bug.

    Now, when mixed binary logging format is in use, statements that exclusively use temporary tables are not logged. Statements that involve a mix of temporary and nontemporary tables are logged on the master only for the operations on nontemporary tables, and the operations on temporary tables are not logged. The exception is if the creation of a temporary table was recorded in the binary log using statement-based format. In this case, a DROP TEMPORARY TABLE IF EXISTS statement is logged on the master when the temporary table is dropped.

    With this change in behavior, the remaining statements in the session that do not involve temporary tables no longer need to be treated as unsafe. The safe statements are now logged in statement-based format, and the unsafe statements are logged in row-based format, according to the normal behavior for mixed format replication, regardless of the presence of temporary tables in the session. Also, the issue reported in the bug has been fixed so that subsequent sessions using the connection now use the appropriate logging format for the session, regardless of the format used by earlier sessions.

    When binlog_format is ROW or STATEMENT, the behavior remains as before. For row-based binary logging format, operations on temporary tables are not logged, with the exception of the DROP TEMPORARY TABLE IF EXISTS statement as for mixed format. For statement-based binary logging format, operations on temporary tables are logged on the master and replicated on the slave, provided that the statements involving temporary tables can be logged safely using statement-based format. binlog_format=STATEMENT is now the only logging mode in which temporary tables are replicated on the slave.

    You cannot now change the binlog_format setting from ROW or MIXED to STATEMENT at runtime, because any CREATE TEMPORARY TABLE statements will have been omitted from the binary log in the previous mode. You can still switch from STATEMENT to ROW or MIXED format, even when temporary tables have been created.

    Thanks to George Lorch and Laurynas Biveinis from Percona for the patch. (Bug #18843730, Bug #72475)

  • Replication: During distributed recovery as part of joining the group, when the applier was signaling that it had applied all transactions, it was also blindly searching for partial transactions. This was to avoid future applier errors, which would happen if the applier stopped at this point. However, this search and remove only made sense for applier stop cases. Upon execution completeness it should not be done, otherwise it can corrupt or purge the applier relay log, which can led to data loss. To solve this issue, when the applier is waiting for execution completeness, it no longer searches for and removes partial transactions. (Bug #88304, Bug #27049034)

  • Replication: In a group with heavy load, joining members could need to retrieve a large amount of data to gain synchrony with the group. If the amount of data retrieved exceeded the View_change packet size of 4Mb the members would fail to join the group and enter Error state. Now, the packet size is taken from slave_max_allowed_packet, which defaults to 1GB. Depending on the load your group processes, you might want to increase the packet size further by configuring slave_max_allowed_packet. (Bug #87701, Bug #26770576)

  • Replication: In a group where a joining member consistently received transactions, the joining member could sometimes not enter the online state. This was due to the way the incoming queue of messages was tested. (Bug #87631, Bug #26731317)

  • Group Replication; Microsoft Windows: On Windows, errors generated by Group Replication now contain a detailed error message rather than just the error number. (Bug #24918678)

  • Group Replication: The thread where the Group Replication plugin was started was not being correctly killed, making it impossible to stop or start the plugin after killing this thread. (Bug #26435775)

  • Group Replication: When transaction_write_set_extraction was enabled, there was a risk of unnecessary serialization while foreign keys were gathered if concurrent DDL took place. Group Replication now takes advantage of the new Data Dictionary to interact with table definitions and foreign keys, which has solved this potential serialization. (Bug #26187850)

  • Group Replication: When group_replication_enforce_update_everywhere_checks is ON, the Group Replication plugin checks whether there are any foreign key cascades and disallows updates to tables affected by them.

    SET NULL operations were not checked as part of this process, which could lead to data inconsistency. Now, when this value is ON, operations on child tables are blocked if the table has a SET NULL option configured. (Bug #25404162)

  • Group Replication: All servers that belong to a group must have unique UUIDs set by server_uuid, but this was not enforced by Group Replication, so that it was possible to add members with duplicate UUIDs. (Bug #88452, Bug #27105803)

  • Group Replication: When starting or stopping, the Group Replication plugin executes internal operations on the server such as enabling or disabling read only mode using an internal session. When this internal session was opened, if the total number of sessions exceeded the number of permitted open sessions set by max_connections, the operation failed as expected but a thread was left behind, which later caused issues. (Bug #88182, Bug #27008102, Bug #27016552)

  • Group Replication: If Group Replication was configured to start on server boot when the server was being initialized using --initialize or --initialize-insecure, because the replication applier infrastructure was not initialized, this resulted in an assertion. Now, Group Replication is not started when the server is being initialized. (Bug #87759, Bug #26802395)

  • Group Replication: Changes to Group Replication variables while starting or stopping the plugin were not being correctly validated. Now, the variables can only be changed if the plugin is not changing state. (Bug #86874, Bug #26372117)

  • Group Replication: Regardless of the number of virtual IPs configured on a machine, Group Replication could access only the first 12 addresses. (Bug #86772, Bug #26324852)

  • Group Replication: The delayed initialization mechanism used for server starts has been improved. Now, it blocks connections only until the server is in read mode. (Bug #86271, Bug #26037344)

    References: See also: Bug #84731, Bug #25475132.

  • Group Replication: When a primary member, such as the primary in a single-primary group or in a multi-primary group which also had asynchronous replication channels feeding data into it, was stopped, the asynchronous channels would continue applying changes. Although super_read_only was set when STOP GROUP_REPLICATION was issued, this did not stop any running asynchronous replication channels already running. This meant that changes could be made locally on the member, and that the asynchronous replication channels had to be stopped manually. Now when Group Replication stops, either due to an error or when STOP GROUP_REPLICATION is issued, all asynchronous replication channels are stopped. (Bug #86222, Bug #26024253)

  • Group Replication: Group Replication logging has been improved, and now includes includes about when a member joins or leaves, when the view changes, and so on. (Bug #84798, Bug #25495393)

    References: See also: Bug #26422857.

  • Linux: On Alpine Linux, mysql would lose its connection to the server if its standard output was not writable. Also, for mysql and mysqldump, order of result flushing for stdout and stderr is now deterministic. (Bug #27169809)

    References: See also: Bug #17583.

  • Microsoft Windows: On Windows, with the myisam_use_mmap and flush system variables enabled, MyISAM did not always flush table files properly. (Bug #26880757)

  • JSON: JSON expressions used as arguments with the LAG() function were not always evaluated correctly. (Bug #26740557)

  • JSON: Repeated execution of a prepared statement that employed JSON_ARRAY() was not handled correctly. (Bug #26704312)

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

  • JSON: When executing the JSON_INSERT() function, the check that is performed to determine whether or not a given insert is being made into the root element tested whether the length of the path was 1—that is, whether the path consisted of a single leg determining which position the inserted element has inside the root element. A problem occurred when there were auto-wrapping path legs at the beginning of the path, in which case a path whose length is greater than 1 might also refer to an element in the root, so that checking the path length did not reliably inform us whether the target element of the insert was the root or some other element.

    To fix this, the check of the path length for detection of the root element has been replaced with a check as to whether the matched element has a parent; if it has none, it must be the root element. (Bug #26649978)

    References: This issue is a regression of: Bug #86213, Bug #26022576.

  • JSON: When serializing a JSON value to its binary representation, it is necessary to make sure that the destination buffer has sufficient space to hold an integer or double value of the required size. Allocation of this buffer previously reserved only the minimum amount of memory needed, which made it very likely that a reallocation would be needed shortly thereafter. This could adversely affect performance, especially when serializing arrays with many numeric values. The serialization is now performed in a manner such that the allocation increases the size of the destination buffer size exponentially, which reduces the amount of the time spent performing this task when processing large arrays. (Bug #88656, Bug #27171283)

  • JSON: When a JSON document was converted to string representation, floating-point values that had no fractional part could be represented such that they became indistinguishable from integers. When the string representation of such a JSON document was passed through the JSON parser again, the information that the numeric value was originally specified as a floating-point value was lost.

    To rectify this problem, a fractional part is now added to the string representation of a floating-point value in a JSON document if the value has no fractional part and is not represented using scientific format. This makes the string representation of a floating-point value distinguishable from that of an integer, so that it continues to be treated as a floating-point number even if the string is parsed again.

    This fix also makes ST_GeomFromGeoJSON() use the same JSON parser as the other JSON functions rather than its own custom parser as had been the case since MySQL 5.7.8; this special handling was due to the fact that ST_AsGeoJSON() dropped the fractional part of negative zero (-0 instead of -0.0), causing the JSON parser to interpret -0 as integer 0, thus losing the distinction between positive and negative zero. Since ST_AsGeoJSON() now uses the standard JSON parser, it represents negative zero as correctly as -0.0, obviating any need for ST_GeomFromGeoJSON() to preserve negative zero explicitly on its own when parsing the output from ST_AsGeoJSON(). (Bug #88230, Bug #27028889)

    References: See also: Bug #19504183.

  • JSON: When inserting JSON values created from the result of a GROUP BY query, the inserted values could sometimes include the concatenation of all the values previously inserted into that column. (Bug #87854, Bug #26867509)

  • JSON: When called using strings extracted from JSON documents as arguments, the LEAD() and LAG() functions returned the same value for every row. (Bug #87839, Bug #26848089)

  • JSON: The microseconds part of the last-updated field in each histogram in the INFORMATION_SCHEMA.COLUMN_STATISTICS table (showing when the histogram was last updated) was dropped when serializing the histogram into JSON and so was not stored. (Bug #87833, Bug #26846289)

  • JSON: When a JSON_SET() statement updated a JSON value to the same value using a partial update (in other words, when the partial update was essentially a NOOP), it was possible that logical diffs for this operation were produced, even though no binary diffs were produced. Now in such cases, neither logical update nor binary diffs are generated. (Bug #87113, Bug #26483625)

  • JSON: Following the implementation of JSON partial updates, the same JSON document could have different binary representations on the master and the slave. This could lead row-based replication—which uses binary equality to find the matching row on the slave—to fail if this occurred. Now the string representation of the JSON document is used for the comparison instead.

    Also as a result of this fix, updates can be skipped in more cases than previously; this is true where the binary representation has changed, but not the contents of the document. (Bug #86532, Bug #26177130)

  • Ubuntu 14.04 and Debian 8 are no longer supported. (Bug #27422291)

  • For builds on 32-bit platforms with Undefined Behavior Sanitizer enabled, a stack-overrun check could cause a server exit. (Bug #27224961)

  • The server could hang during spatial reference system (SRS) creation while another session was using that SRS. (Bug #27220467)

  • A lock for the privilege cache was acquired unnecessarily during privilege-checking operations not involving table permissions. (Bug #27197483)

  • Persisting the read-only gtid_owned or gtid_executed system variable caused an assertion failure at server startup. These variables can no longer be persisted. (Bug #27193853)

  • Improper handling of plugin loading and unloading could cause a server exit. (Bug #27151550, Bug #88589, Bug #27116827, Bug #88483)

  • Error propagation from some windowing functions was not always performed correctly. (Bug #27135084, Bug #27136492)

  • Negation of some very large values was not handled correctly by an internal function. (Bug #27134168)

  • Instituted stricter checks when performing addition involving date intervals. (Bug #27134148)

  • Recently introduced SRID and COLUMN_STATISTICS metadata locks were not instrumented by the Performance Schema. (Bug #27124506)

  • The name of a derived table was not saved before the table was materialized and assigned the name of the temporary table. Later, when trying to reset the table name, this caused the server to fail due to the missing reference to the original value of the name. (Bug #27121663)

  • Performance Schema queries that used indexes on OBJECT_TYPE columns could return incorrect results. (Bug #27121500)

  • Compiling with -DWITH_ASAN=1 and -DWITH_ASAN_SCOPE=1 detected a stack-use-after-scope memory error. (Bug #27108794, Bug #88460)

  • FILE privilege checking for prepared SELECT ... INTO OUTFILE statements was incorrect. (Bug #27094955)

  • Some messages with information priority were written to the error log when log_error_verbosity was less than 3. (Bug #27082862)

  • The ha_create_table_from_engine function failed to pass a table object to the ha_create routine. (Bug #27066335)

  • Partition by and order by elements of unused window definitions were not included when estimating memory requirements. This is resolved by assigning a parsing context (CTX_WINDOW), but only when the current context is CTX_NONE. As part of this fix, unused window definitions are now removed after being checked for syntax and semantic errors. (Bug #27062031)

  • GROUP BY with a ROLLUP that generated NULL was not handled correctly. (Bug #27060420)

  • An Event Scheduler event for which global autocommit was disabled at event expiration time caused an assertion to be raised. (Bug #27041552, Bug #88255)

  • Length calculations for string-valued user-defined variables could be incorrect if the collation was changed. (Bug #27041543, Bug #88256)

  • CREATE TABLE ... SELECT statements that attempted to create a non-InnoDB table raised an assertion if a pre-existing view referenced the table to be created. (Bug #27041536, Bug #88258)

  • When used as an argument to the IF() function, the value of a TIMESTAMP column could be handled differently for different collations. (Bug #27041526, Bug #88259)

  • With statement-based binary logging, using CREATE TABLE ... SELECT to create a BLACKHOLE table caused an assertion to be raised. (Bug #27041516, Bug #88260)

  • For debug builds, a TIMESTAMP-related assertion could be raised with explicit_defaults_for_timestamp enabled. (Bug #27041502, Bug #88261)

  • Under LOCK TABLES, an attempt to execute a DML statement on a table with foreign keys led to assertion failure if the statement was incompatible with the mode under which the tables in the foreign key relationship were locked. (Bug #27041477, Bug #88264)

  • With a LOCK TABLES statement active, queries that select from the INFORMATION_SCHEMA.FILES table could raise an assertion trying to obtain a metadata lock. (Bug #27041452, Bug #88266)

  • Component installation did not properly perform auto-increment handling, which could result in a server exit. (Bug #27041374, Bug #88276)

  • With big_tables=1 and character_set_connection=ucs2, SHOW TABLE STATUS could raise an assertion. (Bug #27041323, Bug #88279)

  • With a backup lock active, removal of binary log files and relay log files incorrectly was permitted. (Bug #27030339, Bug #88238)

  • When evaluating an end-range condition in a scan of a non-covering secondary index, and the end-range condition referenced an indexed virtual column, InnoDB sometimes read the wrong column from the index, which could lead to assertion failures or wrong results. (Bug #27010089)

  • In event items in filter rules, the audit_log plugin did not properly process values specified as a JSON array. (Bug #27010045)

  • An integer overflow was sometimes possible when adding date values, with the potential to return invalid results. (Bug #27004806)

  • TRUNCATE TABLE on an InnoDB table with an active LOCK TABLES raised an assertion if more than one table instance was locked. (Bug #26999526)

  • Some windowing functions including NTH_VALUE() did not return NULL in all cases in which they should have. (Bug #26975882)

  • If one of the temporal arguments to LEAST() or GREATEST() was of type DATETIME, but the aggregated data type was something other than VARCHAR or a temporal type, the LEAST() or GREATEST() item had temporal properties set for it in spite of the fact that it was not of a temporal data type. The temporal properties for the LEAST() or GREATEST() item, including its fractional precision, were therefore not calculated correctly, leading to failure at a later point in statement execution.

    To fix this issue, the data type of LEAST() or GREATEST() is now temporarily set to a temporal type if one or more, but not all, of its arguments are of temporal types regardless of their aggregated data type. (Bug #26975864)

  • IFNULL() did not always check for errors correctly when processing multiple arguments. (Bug #26975848, Bug #27062796, Bug #27062694)

  • With compression enabled for the client/server protocol, logical packets that are multiples of size 0xFFFFFF could cause the connection to be dropped. Thanks to Facebook Inc. for the patch. (Bug #26974113, Bug #88092)

  • Installing and uninstalling a plugin many times from multiple sessions could cause the server to become unresponsive. (Bug #26946491)

  • A virtual column definition that included a function removed in MySQL 8.0 caused startup to fail with a “No database selected” error when starting the MySQL 8.0 server on a MySQL 5.7 data directory. (Bug #26945125, Bug #88040)

  • These errors occurred after an in-place upgrade from MySQL 5.7 to 8.0:

    • Starting the server with an --explicit-defaults-for-timestamp=0 setting returned an Invalid default value for 'cached_time' error.

    • Starting the server with --initialize and --explicit-defaults-for-timestamp=0 configuration settings returned an Invalid default value for 'SET_TIME' error.

    • Duplicate SET data type values caused a Duplicated value in SET error, regardless of the sql_mode configuration setting.

    (Bug #26944731, Bug #88039, Bug #26948678, Bug #88032)

  • Queries with a common table expression and a derived table or view that contained a window function produced incorrect results. (Bug #26907753, Bug #87939)

  • The deprecation warnings were clarified regarding use of the --symbolic-links and --skip-symbolic-links server options (and their equivalents). The server no longer warns about a missing data directory when invoked with the --help option. (Bug #26898576, Bug #87913)

  • VALUES() was not handled correctly in some cases. (Bug #26881946)

    References: See also: Bug #19601973, Bug #17458914.

  • The tablespace discovery mechanism in MySQL Cluster was disabled, which prevented serialized dictionary information from being imported into the data dictionary in cases where the table exists in the storage engine dictionary but not in the MySQL data dictionary. (Bug #26867488)

  • For debug builds, validation checks on relevant generated columns could be missed for UPDATE statements, leading to a server exit. (Bug #26838771)

  • For window functions, an error could be produced that a window was not defined, when it was defined. (Bug #26813454, Bug #87780)

  • When a materialized derived table was determined to be superfluous, the routine that deleted the corresponding object left it in an inconsistent state. Now in such cases, the derived table's TABLE_LIST object left in a consistent state after its materialized object is deleted, by setting its table pointer to NULL. (Bug #26798989)

  • Incorrect results were obtained for a query with MAX() and a HAVING clause used inside a view. (Bug #26781725)

  • Metadata locking for definition changes to tables underlying a view could be inconsistent with metadata locking for other statements on the tables. (Bug #26770836)

  • In MySQL 8.0, view column names are restricted to 64 characters. A MySQL 5.7 view with longer column names was marked as invalid during an upgrade to 8.0 was marked invalid. Now such views produce an error during the upgrade and must be altered to have legal column names before the upgrade will succeed. (Bug #26743291, Bug #87650)

  • Concurrent calls to GET_LOCK() could cause deadlock, even with a wait time of 0. (Bug #26739438, Bug #87620)

  • FROM_UNIXTIME() did not always work correctly with LAG(). (Bug #26739028)

  • Following an INSERT statement with BLOB values in the ON DUPLICATE KEY UPDATE clause that failed with a constraint violation, a similar statement with no reason to return an error could cause a server exit. (Bug #26734162)

  • The Performance Schema now stores rewritten rather than raw SQL statement text when available. (Bug #26732229)

  • Re-executing a prepared statement that used window functions could cause a server exit. (Bug #26730020)

  • An in-place upgrade to MySQL 8.0 caused a server exit if tables contained columns with a pre-5.0 DECIMAL data type. This data type is not supported, so upgrades now detect such columns and warn that in-place upgrade cannot be done. Affected tables must be upgraded by dumping and restoring them. (Bug #26727481)

  • A comparison operator used to order keys in a data dictionary cache hash map incorrectly determined that two storage-engine private IDs used by different storage engines were equal. (Bug #26723442)

  • Values in the XID_GTRID column of the Performance Schema events_transactions_current table were displayed incorrectly for XA transactions. (Bug #26710081, Bug #87559)

  • Incorrect results or a server exit could result when SHA2() was passed a user-defined variable in some character sets. (Bug #26704451)

  • Incorrect NULL handling by LAG() and LEAD() could cause a server exit. (Bug #26703246, Bug #26703156)

  • If an error occurred while setting up the temporary table for duplicate weedout in a semijoin (for example, because the disk was full), the server did not terminate gracefully with an appropriate error message.

    Now in the event that the temporary table is not successfully created, the query is aborted. (Bug #26679983)

  • The server did not always clean up correctly after executing an IN subquery that used a hash semijoin. (Bug #26679495)

  • Building with the -DWITHOUT_SERVER=ON CMake option failed due to attempting to link the authentication_ldap_sasl_client client-side plugin against the embedded server library. (Bug #26665217)

  • During data directory creation or upgrade from MySQL 5.7 to 8.0, server startup would fail due to a Performance Schema initialization failure if the server was started in read_only mode. Additionally, Information Schema metadata was not updated at startup, and Performance Schema and Information Schema version information was stored without verifying that schema tables were created.

    The versioning scheme used for the data dictionary and Information Schema system views is now consistent with the Performance Schema versioning scheme. (Bug #26636238, Bug #87436)

  • The CREATE_OPTIONS column in the INFORMATION_SCHEMA.TABLES table did not show correct information. (Bug #26634507)

  • Incorrect results could be returned for queries that used an outer join and a derived table referenced a const value from an inner table of the outer join. (Bug #26627181)

  • AFTER UPDATE triggers were not invoked for INSERT ... ON DUPLICATE KEY UPDATE when the value to be updated and the new value were the same. (Bug #26626277, Bug #87371)

  • Assignment of anonymous roles to the mandatory_roles system variable was incorrectly permitted. Additionally, assigning a value to mandatory_roles now requires the ROLE_ADMIN privilege, in addition to the SYSTEM_VARIABLES_ADMIN or SUPER privilege normally required to set a global system variable. (Bug #26576989)

  • The server fell back to using the built-in error messages if the lc_messages_dir value was invalid at server startup, but not if lc_messages or lc_time_names were invalid. Now the server uses the built-in messages if any of those variables are invalid at startup. (Bug #26576922)

  • SET DEFAULT ROLE ALL did not include roles named in the mandatory_roles system variable. (Bug #26571995)

  • On Windows, CMake did not automatically add x64 toolchain support for some Visual Studio versions. (Bug #26566360)

  • Problems could occur when a derived table with an ORDER BY clause was merged into an outer query, and when the columns from the ORDER BY were not also referenced in the outer query. (Bug #26542829)

  • Parallel inserts of schema SDI into the SDI B-tree could raise an assertion when creating tables in the same schema in parallel. (Bug #26539665, Bug #87225)

  • Changing the UMASK and UMASK_DIR environment variables from their default values had no effect on database directory and table file access. (Bug #26529942)

  • For debug builds, incorrect nullability assessment of derived table column references could cause CONCAT() to raise an assertion. (Bug #26524721)

  • A server exit could result from simultaneous attempts by multiple threads to register and deregister metadata Performance Schema objects, or to acquire and release metadata locks. (Bug #26502135)

  • MSI packages for Windows failed to detect when Microsoft Visual C++ 2010 Redistributable Package was installed. (Bug #26501092, Bug #87139)

  • Queries that used window functions for tables that contained a BLOB column could cause a server exit. (Bug #26496880)

  • Persisted variables belonging to plugins were not always handled properly at server startup. (Bug #26495619)

  • A server exit could occur for queries that used DISINCT and ORDER BY ... LIMIT and were executed using range access and a temporary table for the ORDER BY. (Bug #26483909)

  • LDAP authentication plugins could fail if their associated system variables were set to invalid values. (Bug #26474964)

  • The Linux RPM spec file for RHEL6 and higher is updated with comments that recommend installing the redhat-rpm-config package to add convenience macros that make rebuilding the RPM package easier. Thanks to Simon Mudd for the patch. (Bug #26474153, Bug #87098)

  • If the error log was misconfigured and the server could not start, no output describing the problem was produced. (Bug #26447825, Bug #87087)

  • When a materialized semijoin operation was evaluated more than once, and one of the tables in the materialization was a const table (that is, with join type JT_CONST), invalid data was accessed during the second materialization when referencing the const table. (Bug #26436185)

  • Password-expiration options did not work correctly for authentication plugins that use external authentication methods. (Bug #26435766)

  • Adding an ORDER BY to a query that included an outer join and a subquery caused a constant value defined for a column in the subquery to be incorrectly promoted to a constant value in the case when the subquery returns 0 rows. (Bug #26432173)

  • For the autocommit system variable, the Performance Schema variables_info table always reported the VARIABLE_SOURCE column as COMPILED. (Bug #26428017)

  • For debug builds, INSERT IGNORE statements that tried to insert NULL into a GEOMETRY NOT NULL column raised an assertion because there is no valid value to convert the NULL to. This is now handled as a nonignorable ER_BAD_NULL_ERROR_NOT_IGNORED error. (Bug #26412713)

  • SET PERSIST_ONLY changed the VARIABLE_SOURCE column of the Performance Schema variables_info table when it should not have. (Bug #26395134)

  • The server failed to check the maximum path length for partition names. (Bug #26390632)

  • Problems occurred when a window with buffering followed an equi-join on a unique index, due to the fact that the window modified the input record with the assumption that, the next time control passes back to the join, a new record was read to the input record. This problem is addressed by reinstating the input record in such cases.

    Note

    This fix was reverted in MySQL 8.0.27.

    (Bug #26389508)

    References: See also: Bug #32820802.

  • Identifiers containing a mixt of backslashes and backticks could be parsed incorrectly. (Bug #26372491)

  • audit_log plugin THD objects could be created with incorrect thread ID information, leading to assertion failure. (Bug #26362452)

  • The HISTOGRAM column in the column_statistics data dictionary table used a key named charset-id to indicate collation numbers. This key has been renamed to collation-id. (Bug #26330090, Bug #86794)

  • Starting the server with the skip_name_resolve system variable enabled could cause localhost in account entries to match non-localhost hosts. (Bug #26328274, Bug #26202411, Bug #86546)

  • if a configured error log service existed but could not be initialized, log information was lost. Now if a log service is configured at startup but cannot be initialized, diagnostics about the problem are sent to the default log service (or if that fails, directly to the error stream), and the server exits. If a log service is configured at runtime but cannot be initialized, diagnostics are sent to the client. (Bug #26286871, Bug #86728)

  • Installing and uninstalling Performance Schema example plugins concurrently with deletes from tables associated with those plugins could cause a server exit. (Bug #26281359)

  • When HASH_SCAN was specified as one of the values for the slave_rows_search_algorithms system variable, which is the default from MySQL 8.0.2, and row-based replication was in effect, updates to a table containing virtual generated fields could raise an assertion. The issue was caused by an error when generating string representations of the virtual generated fields in order to create hashes for use in searches. To remove the issue, MySQL no longer creates hashes for virtual generated fields. (Bug #26280724)

  • The server permitted SHOW CREATE TABLE on nontable files created for full-text searching. (Bug #26271244)

  • For debug builds, CREATE OR REPLACE VIEW for an existing view raised an assertion for column names greater than 64 characters. Now an appropriate error is reported. (Bug #26266789)

  • SET PERSIST could be ineffective due to sorting variables written to mysqld-auto.cnf. Variables are now written in the order persisted. (Bug #26259671)

  • Attempting a partial backup with mysqlpump on a GTID-enabled server failed and produced an error message suggesting incorrectly that this was not possible. (It is possible using the --set-gtid-purged option.) (Bug #26199978)

  • GRANT GRANT OPTION ON *.* TO user granted GRANT OPTION for static but not dynamic privileges. REVOKE ALL ... FROM CURRENT_USER() revoked static but not dynamic privileges. (Bug #26191109, Bug #25658967)

  • Error logging could attempt to log freed messages, resulting in a server exit. (Bug #26188656, Bug #86562)

  • A HAVING condition was optimized away for an alias on an aggregate column where there was no GROUP BY clause. (Bug #26188578)

  • ST_Crosses() could return an incorrect result when at least one parameter is a geometry collection and multiple elements of the geometry collection must be taken into account in order to determine whether the geometries cross. (Bug #26188208, Bug #86559)

  • MBROverlaps() incorrectly returned false for two crossing perpendicular lines. (Bug #26188118, Bug #86558)

  • ALTER USER user DEFAULT ROLE ALL produced an error. (Bug #26174169)

  • mysqldump exited abnormally for large --where option values. (Bug #26171967, Bug #86496, Bug #27510150)

  • A query using a window function with a window which partitioned or ordered on the result of an aggregate function where this evaluated as NULL returned incorrect results. (Bug #26164633)

  • The Performance Schema could leak memory due to nondeletion of file instances created for ALTER TABLE operations that used the table-copy algorithm. (Bug #26152751, Bug #86482)

  • Failed creation of a temporary table using REPLACE could under some circumstances result in an assertion in a later statement. (Bug #26126789, Bug #86422)

  • mysqlpump did not properly parse TABLESPACE clauses in the result from SHOW CREATE TABLE statements it executed to determine table structure. (Bug #26116415)

  • The binary file for the udf_example loadable function was omitted from binary distributions. (Bug #26115002, Bug #29178542)

  • Long SET PERSIST statements could cause a server exit. (Bug #26100122)

  • An incorrect formula was used to calculate maximum length of result strings for a few string functions: QUOTE(), AES_DECRYPT(), and WEIGHT_STRING(). This could affect, for example, the length of character columns created for CREATE TABLE ... AS SELECT ... QUOTE(). (Bug #26049942, Bug #86305)

  • Schema creation and removal operations could fail due to checking for schema directories under the data directory rather than checking the data dictionary. (Bug #26043994, Bug #86282)

  • SHOW PLUGINS did not handle plugins that were terminating, resulting in a server exit. The statement now displays the status for such plugins as DELETING. (Bug #26029765, Bug #86243)

  • Some statements could cause a buffer overflow in the digest code. Thanks to Laurynas Biveinis and Roel van de Paar for the patch. (Bug #26021187)

  • Previously, when the Performance Schema failed to initialize, it wrote a nonspecific init failed warning to the error log. Now it prints more specific messages about which memory allocation failed. (Bug #25996291)

  • Incorrect results could occur on a table with a unique index when the optimizer chose a Loose Index Scan even though the unique index had no index extensions. (Bug #25989915, Bug #86165, Bug #26532061, Bug #87207)

    References: This issue is a regression of: Bug #21749123, Bug #78244.

  • For XA COMMIT, precommit handling could set an error in the diagnostics area that was not reported correctly on the calling side, causing an assertion to be raised. (Bug #25978684, Bug #86142)

  • The MIN_VALUE column of the Performance Schema variables_info table displayed incorrect values on 32-bit big-endian platforms. (Bug #25967079)

  • A memory leak occurred when the optimizer excluded a subquery associated with a temporary table. (Bug #25951134)

  • An assertion could be raised for updates when a view or derived table considered read only had nested references not seen as read only. (Bug #25832861, Bug #85796)

  • Certificate and key files automatically generated by the server could have an incorrect access mode. (Bug #25832856)

  • Queries on the INFORMATION_SCHEMA TABLES and STATISTICS tables, if evaluated using Index Condition Pushdown, could push down internal data dictionary functions, resulting in an assertion being raised. (Bug #25820175, Bug #85765)

  • ST_AsText() could read freed memory. (Bug #25818451)

  • CREATE USER IF NOT EXISTS was not written to the binary log if the user existed. This could result in inconsistent replication behavior if the user did not exist on slave servers. A similar issue occurred for ALTER USER IF EXISTS. To avoid inconsistencies, these statements now are written to the binary log. (Bug #25813089, Bug #85733)

  • An invalid utf8 input string caused a heap buffer overflow error. (Bug #25811623, Bug #25946444)

  • A race condition made it possible to cause a server exit by persisting variables from multiple sessions simultaneously. (Bug #25768813)

  • Plugins can create or drop INFORMATION_SCHEMA tables, but views that reference INFORMATION_SCHEMA tables were not validated when plugins were unloaded or unloaded. (Bug #25761992, Bug #85579)

  • mysql wrote some password-related statements to the .mysql_history file. (Bug #25750609)

  • Incorrect handling of internal memory buffers could cause a server exit. (Bug #25737271)

  • On a read-only server with GTIDs enabled, a DROP TEMPORARY TABLE IF EXISTS statement relating to a nonexistent or filtered table could write an unnecessary transaction to the binary log and create an unnecessary GTID. In this situation, the missing temporary table was previously assumed to be transactional, leading to the statement being split. Now, MySQL checks that the temporary table exists and that its DROP TEMPORARY TABLE statement is recorded in the binary log. If this is not the case, no GTID is created. Thanks to Laurynas Biveinis for the patch. (Bug #25656992, Bug #85258)

  • The MeCab full-text parser plugin failed to load on Windows. (Bug #25633175)

  • The SET_TIME column of the Performance Schema variables_info table was initialized incorrectly. (Bug #25608115)

  • Executing a stored procedure containing a statement that created a table from the contents of certain SELECT statements could result in a memory leak. (Bug #25586773)

  • The Performance Schema failed to check the maximum host length for client connections. (Bug #25510805)

  • For spatial functions, some set operations produced a result with SRID 0 when given arguments in a different SRID. (Bug #25510403)

  • Large --ssl-cipher values could cause client programs to exit. (Bug #25483593)

  • A missing argument-count check during preparation of a stored procedure call could result in a server exit. (Bug #25398451, Bug #84512)

  • Temporary tables used in processing a recursive common table expression with UNION DISTINCT and a great many columns now use the MEMORY engine instead of InnoDB. (Bug #25190109)

  • If the MySQL root user account was renamed, a query that accessed an INFORMATION_SCHEMA view returned an error stating that the user specified as the definer does not exist. To avoid this error, a new reserved account, 'mysql.infoschema'@'localhost', is now the DEFINER for INFORMATION_SCHEMA views. (Bug #25185947, Bug #84027)

  • When an UPDATE required a temporary table having a primary key larger than 1024 bytes and that table was created using InnoDB, the server could exit. (Bug #25153670)

  • SET DEFAULT ROLE was not transactional like other account-management statements. (Bug #25122897)

  • mysqlpump included the gtid_executed table in dumps of the mysql system database, causing the gtid_executed position to be lost upon server restart after the dump was reloaded. mysqlpump no longer dumps the gtid_executed table. (Bug #25109007)

  • For geometry calculations, invalid input parameters could lead to an incorrect result buffer and cause an assertion to be raised or a server exit. (Bug #25062396)

  • IFNULL(decimal, int) could lose a digit after the decimal point when used in a query that included GROUP BY and was executed using a temporary table. (Bug #25051195, Bug #83699)

  • For some queries, such as those involving UNION, column width for GROUP_CONCAT() could be calculated incorrectly, leading to incorrect application of group_concat_max_len. (Bug #25050090, Bug #83667)

  • Audit logging of events for the Performance Schema global_variables table was improved so as to not report events for rows materialized but not reported to the SQL layer. (Bug #24970428)

  • ST_Buffer() could return an invalid result or raise an error for some inputs that should have produced a valid output geometry. (Bug #24947868, Bug #26735293, Bug #25662426)

  • For builds with AddressSanitizer or Undefined Behavior Sanitizer enabled, division by zero could occur during Performance Schema timer initialization. (Bug #24785784)

  • Operations that rely heavily on the metadata locking (MDL) subsystem caused a performance degradation. Traversal of MDL ticket lists was time consuming in cases where there were large number of MDL tickets. (Bug #24734971, Bug #83143)

  • When binlog_format is ROW or MIXED, operations on temporary tables are not logged. Previously, the exception to this rule was that when the connection was terminated at the end of the session, the statement DROP TEMPORARY TABLE IF EXISTS was logged for any temporary tables that had been opened in the session. For row-based replication, this behavior caused an unnecessary write to the binary log, and added a transaction sequence number for the GTID where these were enabled.

    Now, when a temporary table is created in a session, the binary logging format is tracked. The DROP TEMPORARY TABLE IF EXISTS statement is only logged at the end of the session if statement-based format was in effect when the temporary table was created, so the CREATE TEMPORARY TABLE statement was logged. If row-based or mixed-format binary logging was in use when the table was created, the DROP TEMPORARY TABLE IF EXISTS statement is not logged.

    Thanks to Laurynas Biveinis for the patch. (Bug #24670909, Bug #83003, Bug #28606948)

  • Concurrent INSERT, ALTER TABLE, and DROP DATABASE operations could result in deadlock. (Bug #24510948, Bug #82704)

  • Under some conditions, the audit_log plugin could recursively lock a mutex, resulting in an unresponsive server. (Bug #24437533)

  • In some cases, the optimizer chose a Loose Index Scan (QUICK_GROUP_MIN_MAX_SELECT) for a GROUP BY query even when there was a predicate with a disjunction. This is fixed by not performing a range scan when the condition in the WHERE clause results in more than one disjoint range tree. (Bug #24423143)

  • Incorrect results could occur when the optimizer chose an index on a generated column to fetch values. (Bug #24345509, Bug #29451999)

  • Debug symbol packages are now included for all apt platforms (previously, they were only available on Debian 9). (Bug #24008883, Bug #27990381)

  • With SQL_MODE='', UNIX_TIMESTAMP(COUNT(1)) returned NULL instead of 0 as expected. (Bug #23529242)

  • When deleting rows from a table that had an indexed virtual BLOB column with a NOT NULL constraint, and the generated column expression evaluated to NULL in one of the rows that were being deleted, conversion of the NULL to its NOT NULL equivalent was not performed correctly. (Bug #23321196)

    References: See also: Bug #23037025, Bug #21345972.

  • Setting the MYSQL_GROUP_SUFFIX environment variable had no effect. (Bug #23072792)

  • A missing check for error handling during generated column evaluation could result in a server exit. (Bug #23021693)

  • To check whether a table was empty, ALTER TABLE performed a table scan, which is inefficient. (Bug #22688065)

  • Failure to acquire tablespace metadata locks for ALTER TABLE when a LOCK TABLES was active could cause an assertion to be raised. (Bug #22486020, Bug #79820)

  • Constant propagation is no longer performed when a constant expression contains a reference to the column it is meant to replace. (Bug #20964700)

  • Queries with many left joins were slow if join buffering was used (for example, using the block nested loop algorithm). (Bug #18898433, Bug #72854)

  • REGEXP failed to find matches occurring after a \0 character in the string expression. (Bug #17541193, Bug #70470)

  • Selecting from a view that involved aggregation and WITH ROLLUP could result in a spurious Column col_name cannot be null error. (Bug #11755860, Bug #47693)

  • COALESCE() could change the value of FLOAT fields. (Bug #11751705, Bug #42666)

  • In some cases, the row estimate used by the server to determine whether to use sampling could be inaccurate. This was because the histogram process assumed that the estimate for the number of rows in the table was current, although it was not updated by (for example) INSERT or DELETE statements. Now the histogram process requests an updated count of rows. (Bug #88710, Bug #27197709)

  • Long-running regular expression matches could not be killed. (Bug #88676, Bug #27183583)

  • An optimizer SET_VAR hint (see Variable-Setting Hint Syntax) setting cte_max_recursion_depth was ignored. (Bug #88594, Bug #27153338)

  • When handling range frames, if the first row for a range frame was found, its position was not stored. This could later cause retrieval of the row from the frame buffer to fail. (Bug #88568, Bug #27149369)

  • The server did not handle triggers activated by LOAD DATA correctly when --skip-log-bin was enabled. (Bug #88516, Bug #27128534)

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

  • Stored procedures performing XA transactions and acting on views were not executed correctly. (Bug #88326, Bug #27058931)

  • When a table contained a column whose length was zero, the optimizer could in some cases allocate a record buffer that was too small to hold the columns read by the query. (Bug #88283, Bug #27041288)

  • A trigger containing invalid syntax, followed by an INSERT that did not specify a column list, attempted to insert a new row regardless. (Bug #88274, Bug #27041382)

  • Window functions did not always produce correct results with LAST_VALUE() and frames having multiple ORDER BY expressions. (Bug #88186, Bug #27010574)

  • A fix for a previous issue caused the aggregated data type to be set to VARCHAR whenever the result type was string and the column size was larger than 255 characters (maximum length for CHAR). This caused problems for data types such as JSON whose result type is a string, but which support field values longer than 255 characters. Now in such cases the data type is set explicitly to VARCHAR when an aggregated column is of type CHAR or BINARY (both represented internally as strings) but its size exceeds the maximum for CHAR. (Bug #88073, Bug #26960106)

    References: This issue is a regression of: Bug #83895, Bug #25123839.

  • A prepared statement containing an ORDER BY list that referred to a parameter was not always handled correctly. (Bug #87863, Bug #26867652)

  • DENSE_RANK() did not work correctly for the first row in a partition when buffering was in use, due to premature initialization of the cache comparator for ORDER BY. (Bug #87760, Bug #26802696)

  • The optimizer chose a composite index for ref access where only the first part of the key could be used. The composite key was suitable but was seen as a higher cost. This was because, when choosing between ref access and range access on the same index, we prefer range if certain criteria are fulfilled, one of these being to choose to avoid ref-access if it has an overly-optimistic or unrealistically low cost as can happen when records_per_key is very low. This was done even if the estimate of the number of rows for range access was more reliable than the estimate for ref access. (Bug #87613, Bug #26727773)

    References: See also: Bug #23259872.

  • When a stored function was used with a table column value as an argument in a WHERE predicate, its internal not_null_tables property was falsely set to a nonempty value. If this predicate was applied to an outer join operation and one of the arguments was from an inner table of the outer join, the predicate was sometimes used (incorrectly) to convert the outer join to an inner join. According to the SQL standard, only functions that have the RETURNS NULL ON NULL INPUT property should behave in that manner. Since MySQL does not currently implement this property, stored functions are changed such that they no longer implement the RETURNS NULL ON NULL INPUT behavior. (Bug #86922, Bug #26389402)

  • A view or derived table contained incorrect data when defined using a SELECT that performed aggregation of a column, and whose result was filtered with HAVING. (Bug #86840, Bug #26360114)

  • The server handled triggers and generated columns incorrectly. (Bug #86637, Bug #26251621)

  • A query that grouped results on a subquery which returned a BLOB (or a type based on BLOB such as JSON) sometimes failed to find the group boundaries, and so returned incorrect results. (Bug #78787, Bug #21974696)


PREV   HOME   UP   NEXT
Related Documentation
MySQL 8.0 Reference Manual
Download these Release Notes
PDF (US Ltr) - 4.2Mb
PDF (A4) - 4.3Mb