MySQL Community Server 8.0.19 has been released, part 2/2
Posted by: Bjørn Munch
Date: January 13, 2020 06:59AM
Date: January 13, 2020 06:59AM
[ This is part 2, section "Bugs Fixed" ]
Edited 1 time(s). Last edit at 01/13/2020 07:03AM by Bjørn Munch.
* Partitioning: When upgrading a database with a subpartitioned table from MySQL 8.0.16 or lower and then executing ALTER TABLE ADD COLUMN, an assertion or error would occur. (Bug #30360695, Bug #97054) * Partitioning: During upgrade of partitioned tables from MySQL 5.7 to 8.0, when a prefix key was used by the partitioning function, the prefix length was ignored, and the full column length was considered instead. Consequently, the table might incorrectly be rejected from being upgraded because its partition field length was found to be too large. (Bug #29941988, Bug #95921) * Partitioning: ALTER TABLE ... EXCHANGE PARTITION could cause indexes to become corrupted. This was due to the fact that the server assumed that the order in which an index is created in a partitioned table is the same as that of the table which is not partitioned. This led to the wrong index data being exchanged. (Bug #29706669) * Replication: When a member is joining or rejoining a replication group, if Group Replication detects an error in the distributed recovery process (during which the joining member receives state transfer from an existing online member), it automatically switches over to a new donor, and retries the state transfer. The number of times the joining member retries before giving up is set by the group_replication_recovery_retry_count system variable. The Performance Schema table replication_applier_status_by_worker displays the error that caused the last retry. Previously, this error was only shown if the group member was configured with parallel replication applier threads (as set by the slave_parallel_workers system variable). If the group member was configured with a single applier thread, the error was cleared after each retry by an internal RESET SLAVE operation, so it could not be viewed. This was also the case for the output of the SHOW SLAVE STATUS command whether there were single or multiple applier threads. The RESET SLAVE operation is now no longer carried out after retrying distributed recovery, so the error that caused the last retry can always be viewed. (Bug #30517160, Bug #30517172) * Replication: An assertion was raised when privilege checks were carried out for a replication channel if the slave had more columns in the relevant table than the master. The check now references the number of columns in the event, rather than in the table definition. (Bug #30343310) * Replication: When a replication group member leaves a group, either because STOP GROUP_REPLICATION was issued or due to an error, Group Replication now stops the binary log dump thread so that the former group member cannot send unwanted binary log data to the members that have remained in the group. (Bug #30315614) * Replication: Replication connection parameters that are held in the mysql.slave_relay_log_info table are now preserved in the event of a server crash or deliberate restart after issuing RESET SLAVE but before issuing START SLAVE. This action applies to the PRIVILEGE_CHECKS_USER account setting for replication privilege checks (introduced in MySQL 8.0.18) and the REQUIRE_ROW_FORMAT setting (introduced in MySQL 8.0.19). Note that if relay_log_info_repository=FILE is set on the server (which is not the default and is deprecated), replication connection parameters are not preserved in this situation. (Bug #30311908) * Replication: When a replication channel is secured by specifying a PRIVILEGE_CHECKS_USER account, which should not have ACL privileges, a GRANT statement that is replicated to the channel causes the replication applier to stop. In this situation, the behavior was correct but an assertion was being raised. The assertion has now been removed. (Bug #30273684) * Replication: When Group Replication was started following either provisioning with a cloning operation, execution of RESET MASTER, or removal of a partial transaction from the relay log, RESET SLAVE ALL was used internally to clear any unwanted state on the server. However, in MySQL 8.0.18, this caused any PRIVILEGE_CHECKS_USER account that was specified for a Group Replication channel to be removed. RESET SLAVE is now used instead, which does not remove the account. (Bug #30262225) * Replication: For multithreaded replication slaves, setting slave_preserve_commit_order=1 now preserves the order of statements with an IF EXISTS clause when the object concerned does not exist. Previously, these updates might have committed before transactions that preceded them in the relay log, which might have resulted in gaps in the sequence of transactions that have been executed from the slave's relay log. (Bug #30262096) * Replication: When privilege checks were carried out for a replication channel, the permissions required for setting the session value of the sql_require_primary_key system variable were not being checked. The check is now carried out. (Bug #30254917) * Replication: A memory leak could occur when a failed replication group member tried to rejoin a minority group and was disallowed from doing so. (Bug #30162547, Bug #96471) * Replication: When a group member rejoins a replication group, it begins the distributed recovery process by checking the relay log for its group_replication_applier channel for any transactions that it already received from the group, and applying these. The joining member then initiates state transfer from an existing online member, which might begin with a remote cloning operation. Previously, the group_replication_applier channel was not explicitly stopped when a remote cloning operation was started, so it was possible that the applier might still be applying existing transactions at that time, which might lead to errors. The group_replication_applier channel is now stopped before a remote cloning operation is requested, and restarted when the distributed recovery process moves on to state transfer from a donor's binary log. (Bug #30152028) * Replication: If STOP GROUP_REPLICATION was issued while the member's XCom port was blocked, the XCom thread hung and the shutdown did not complete. XCom is now terminated in this situation. (Bug #30139794) * Replication: When Group Replication is running in single-primary mode, and a new primary server is elected, the messages logged at this time now provide the newly elected primary server's gtid_executed set, and the set of GTIDs retrieved by the replication applier. (Bug #30049310) * Replication: The slave status logs mysql.slave_relay_log_info (the relay log info log) and mysql.slave_worker_info (the slave worker log) are now copied from the donor to the recipient during a local or remote cloning operation. The slave status logs hold information that can be used to resume replication correctly after the cloning operation, including the relay log position from which to restart replication, the PRIVILEGE_CHECKS_USER account setting, and the new REQUIRE_ROW_FORMAT setting. Note that the relay logs themselves are not copied from the donor to the recipient, only the information about them that is held in these tables. Also note that if relay_log_info_repository=FILE is set on the server (which is not the default and is deprecated), the slave status logs are not cloned; they are only cloned if TABLE is set. Before this patch, the following replication-related behaviors occurred on a replication slave that had been provisioned by a cloning operation: + The default replication channel would fail to start if it was the only channel on the slave, because it was considered to be not initialized due to the missing relay log information. + Any PRIVILEGE_CHECKS_USER account setting that had been applied to replication channels on the donor was absent and had to be respecified. + Replication channels that used GTID auto-positioning (as specified by the MASTER_AUTO_POSITION option on the CHANGE MASTER TO statement) were able to resume replication automatically. + Replication channels that used binary log file position based replication (as specified by the MASTER_LOG_FILE and MASTER_LOG_POS options on the CHANGE MASTER TO statement) had to have the MASTER_LOG_FILE and MASTER_LOG_POS options reapplied manually before restarting replication in order to resume correctly. If the channels were configured to start replication automatically at server startup, without the options reapplied they would attempt to start replication from the beginning. They were therefore likely to attempt to replicate data that had already been copied to the slave by the cloning operation, causing replication to stop and possibly corrupting the data on the slave. With this patch, the following replication-related behaviors now occur on a replication slave that has been provisioned by a cloning operation: + The default replication channel can now always start after the cloning operation if it is configured to do so. + All channels now have the donor's PRIVILEGE_CHECKS_USER account setting and REQUIRE_ROW_FORMAT setting. + Replication channels that use GTID auto-positioning (as specified by the MASTER_AUTO_POSITION option on the CHANGE MASTER TO statement) are still able to resume replication automatically. For Group Replication channels, which use GTID auto-positioning, an internal equivalent of the RESET MASTER statement is now used to ensure that replication resumes optimally. + Replication channels that use binary log file position based replication now have the correct MASTER_LOG_FILE and MASTER_LOG_POS options in place after cloning. Because the relay logs themselves are not cloned, these channels now attempt to carry out the relay log recovery process, using the cloned relay log information, before restarting replication. For a single-threaded slave (slave_parallel_workers is set to 0), relay log recovery should succeed in the absence of any other issues, enabling the channel to resume replication correctly. For a multithreaded slave (slave_parallel_workers is greater than 0), relay log recovery is likely to fail because it cannot usually be completed automatically, but an informative error message is issued, and the data will not be corrupted. (Bug #29995256, Bug #30510766) * Replication: An internal deadlock could occur on a multi-threaded replication slave when the relay_log_space_limit system variable was set to limit the size of relay logs on the slave, and the coordinator thread acquired locks related to this limit and to the end position of the log. (Bug #29842426) * Replication: If a replication group member stops unexpectedly and is immediately restarted (for example, because it was started with mysqld_safe), it automatically attempts to rejoin the group if group_replication_start_on_boot=on is set. Previously, if the restart and rejoin attempt took place before the member's previous incarnation had been expelled from the group, the member could not rejoin. Now in this scenario, Group Replication automatically uses a Group Communication System (GCS) feature to retry the rejoin attempt for the member 10 times, with a 5-second interval between each retry. This should cover most cases and allow enough time for the previous incarnation to be expelled from the group, letting the member rejoin. Note that if the group_replication_member_expel_timeout system variable is set to specify a longer waiting period before the member is expelled, the automatic rejoin attempts might still not succeed. (Bug #29801773) * Replication: If a replication slave was set up using a CHANGE MASTER TO statement that did not specify the master log file name and master log position, then shut down before START SLAVE was issued, then restarted with the option --relay-log-recovery set, replication did not start. This happened because the receiver thread had not been started before relay log recovery was attempted, so no log rotation event was available in the relay log to provide the master log file name and master log position. In this situation, the slave now skips relay log recovery and logs a warning, then proceeds to start replication. (Bug #28996606, Bug #93397) * macOS: On macOS, configuring MySQL with -DWITH_SSL=system caused mysql_config output to incorrectly include internal CMake names for the static SSL libraries. (Bug #30541879, Bug #97632) * macOS: Builds on macOS with Ninja could fail with an error trying to create a symbolic link multiple times. (Bug #30368985) * Microsoft Windows; JSON: On Windows platforms, memory used for a multi-valued index was not released after the table containing it was dropped. (Bug #30227756) * Microsoft Windows: On Windows, -DWITH_SSL=system failed to find the installed OpenSSL headers if Strawberry Perl was installed. (Bug #30359287) * Microsoft Windows: On Windows, the -DWITH_SSL=system option did not work if the path name leading to the system OpenSSL libraries contained a space. This is now handled. Also, -DWITH_SSL=yes is treated like -DWITH_SSL=system, as on other platforms. (Bug #30261942, Bug #96739) * Microsoft Windows: MSVC 2019 produced garbled source file names for compilation errors. A workaround in the CMake configuration was implemented to correct for this. (Bug #30255096, Bug #96720) * JSON: Updating a value in a JSON column by replacing a character string element with a binary string containing the same byte sequence as the utf8mb4 representation of the character string had no effect. The root cause of this issue was a change in the behavior of comparisons between JSON strings and JSON opaque values introduced by the implementation of multi-valued indexes in MySQL 8.0.17, previous to which, JSON strings and JSON opaque values were never considered equal. After the change, they were considered equal if their binary data matched. An analysis of this change showed that it was not needed; in addition, the new behavior conflicted with the existing documentation for comparisons of JSON values. This issue is fixed by restoring the original behavior. (Bug #30348554) * JSON: A view that used JSON_TABLE() did not preserve the character set in which JSON path arguments were encoded. This meant that, if the view was evaluated with a different character set in effect from the one in which it was defined, it could produce wrong results. This is fixed by ensuring that JSON_TABLE() preserves the original character set in such cases. (Bug #30310265) * JSON: Adding a functional index on a JSON column changed the collation used for comparing strings, causing the result returned by the same query selecting the column to differ from that obtained without the index. (Bug #29723353) * JSON: If the first argument to JSON_TABLE() was const during the execution of a stored procedure, but not during preparation, it was not re-evaluated when a statement was subsequently executed again, causing an empty result to be returned each time following the first execution of the procedure. (Bug #97097, Bug #30382156) * JSON: In some cases, such as when a query uses FORCE INDEX, the cost of reading the table is DBL_MAX; this was rounded up to 2e308 when printed, which is too large for the JSON parser, so that it was not possible to extract parts of the optimizer trace using a query such as SELECT JSON_EXTRACT(trace, '$**.table_scan') FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE. Now in such cases, values greater than 1.5e308 are rounded down and printed as 1e308 instead. (Bug #96751, Bug #30226767) * After upgrading from MySQL 5.7 to MySQL 8.0, a CLONE INSTANCE operation failed with the following error: ERROR 3862 (HY000): Clone Donor Error: 1016 : Can't open file: './undo001'. The upgrade process left behind orphaned in-memory undo tablespaces. Thanks to Satya Bodapati for the contribution. (Bug #30602218, Bug #97784, Bug #30239255, Bug #96637) * The thread_pool plugin used display widths in definitions for integer columns of Performance Schema tables. This resulted in warnings written to the error log because integer column display widths are now deprecated. (Bug #30597673) * The MySQL optimizer's hash join algorithm uses the join buffer to store intermediate results. If this buffer overflows, the server uses a spill-to-disk algorithm, which writes one of the hash join operands to a temporary file, to handle this gracefully. If one of the operands was a table that was a member of a pushed join operation, this strategy conflicted with the pushed join requirement for all child result rows to use nested-loop reads whenever one of their pushed join ancestors was the current row in the join evaluation, which could in some cases result in incorrect query results being returned. (Bug #30573733) * Access to the INFORMATION_SCHEMA.VIEWS table was not properly restricted to the correct user. (Bug #30542333) * When creating hash values used for lookups during a hash join, the server did not respect the PAD SPACE attribute, meaning that 'foo' and 'foo ' did not match when using a PAD SPACE collation. This is fixed by padding all strings up to the same length as the longest possible string, where the longest possible string is deduced from the data type length specifier N in CHAR(N) or VARCHAR(N). (Bug #30535541) * When retrieving large result sets containing DECIMAL columns from a secondary engine, conversion of the column values to strings for transport over the text protocol acted as a bottleneck. The performance of the functions responsible for such conversions has been improved in some cases by as much as 50%, as reflected in internal testing. (Bug #30528427) * When the FORMAT_PICO_TIME() function was invoked to process several rows, once a NULL argument was found in a row, every result after that was set to NULL. (Bug #30525561) * When a Performance Schema event was timed, the event duration reported in events_xxx tables could be NULL instead of 0 for events where the timer start and end values are equal. (Bug #30525560) * Adding a LIMIT clause to a parenthesized query suppressed locking clauses within the parentheses. For example, this query would not lock the table: (SELECT ... FOR UPDATE) LIMIT ...; Adding a LIMIT clause outside of a parenthesized query is intended to override a LIMIT clause within the parentheses. However, the outer LIMIT suppressed ORDER BY within the parentheses as well. For example, for this query, the ORDER BY was suppressed: (SELECT ... ORDER BY ... LIMIT a) LIMIT b; Now inner locking and ORDER BY clauses are not suppressed by an outer LIMIT clause. (Bug #30521098, Bug #30521803) * When optimizer extracts conditions on constant tables for early evaluation, it does not include WHERE conditions that are expensive to evaluate, including conditions involving stored functions. When the extracted condition evaluated to true because it involved only const tables, the entire WHERE condition was incorrectly removed. Now in such cases, a check for expensive conditions is performed prior to any removal of the WHERE condition. (Bug #30520714) * When a lateral materialized derived table used DISTINCT, the derived table was not rematerialized for each outer row as expected. (Bug #30515233) * EXPLAIN ANALYZE did not work correctly with a common table expression using WITH RECURSIVE. (Bug #30509580) * The GNU gold loader could cause memory exhaustion on some platforms. Now it is used by default only on Intel 64-bit platforms. (Bug #30504760, Bug #96698) * Some Linux platforms experienced high overhead with EXPLAIN ANALYZE due to use of a system call by libstdc++ instead of clock_gettime(). (Bug #30483025) * On Solaris 11.4, the LDAP authentication plugins could not be built. (Bug #30482553) * Queries that used the MEMBER OF() operator were not always handled correctly. (Bug #30477993) * Boost compilation failed under Visual Studio due to a Boost workaround for a VC++ 2013 bug that has since been fixed. The workaround is now patched for Boost compilation with MySQL. (Bug #30474056, Bug #97391) * When retrieving large result sets containing many integers from a secondary engine, conversion of the integers to strings for sending over the text protocol could act as a bottleneck. To avoid this problem, the performance of internal functions performing such conversions has been improved. (Bug #30472888) * Docker packages were missing the LDAP authentication plugins. (Bug #30465247) * Corrected a typo in a mysys/my_handler_errors.h error message. Thanks to Nikolai Kostrigin for the contribution. (Bug #30462329, Bug #97361) * A GTID table update while innodb_force_recovery was enabled caused a debug assertion failure. (Bug #30449531, Bug #97312) * MySQL failed to compile against Protobuf 3.10. (Bug #30428543, Bug #97246) * Buffered log lines during system startup could be lost. (Bug #30422941, Bug #97225) * If the mysql.user system table was renamed, the server could exit. (Bug #30418070) * Revoking a role specified with no host name could cause a server exit. (Bug #30416389) * When determining whether to pull out a semijoin table when other tables inside the semijoin depended on this table, only those semijoin tables which were base tables were considered; those in nested joins were ignored. (Bug #30406241) References: See also: Bug #12714094, Bug #11752543, Bug #43768. * The AppArmor profile on Ubuntu platforms was not able to read the OpenSSL configuration. (Bug #30375723) * Some Fedora 30 packages had missing obsoletes information that could cause problems upgrading an existing MySQL installation. (Bug #30348549, Bug #96969) * Altering only the default encryption in an ALTER SCHEMA statement caused the schema default character set and collation to be reset to the system defaults. (Bug #30344462, Bug #96994) * Columns declared with both AUTO_INCREMENT and DEFAULT value expressions (a nonpermitted combination) could raise an assertion or cause a server exit. (Bug #30331053) * SHOW GRANTS for an anonymous user could result in a server exit under some conditions. (Bug #30329114) * GREATEST() and LEAST() did not always handle time values correctly. (Bug #30326848) References: This issue is a regression of: Bug #25123839. * The list of subpartitions in partition objects was not serialized and therefore not included in serialized dictionary information (SDI). To address this issue, support was added for serialization and deserialization of subpartition dictionary information. The patch for this bug also includes minor SDI code refactoring and format changes. Due to the format changes, the SDI version number was incremented. (Bug #30326020, Bug #96943) * Following execution of ANALYZE TABLE, the optimizer trace for a given query differed when another query was executed previously to it, but also after the ANALYZE TABLE. (Bug #30321546) * innodb_buffer_pool_instances was not initialized correctly at server startup if it had been set using SET PERSIST or PERSIST_ONLY. (Bug #30318828) * A low max_allowed_packet value caused the following error: ERROR 1153 (08S01) at line 1: Got a packet bigger than 'max_allowed_packet' bytes. The error message was revised to indicate the minimum required max_allowed_packet value for cloning operations. (Bug #30315486, Bug #96891) * An assertion could be raised when server code tried to send to clients an error code intended to be written to the error log. These instances are fixed by sending a code intended to be sent to clients. (Bug #30312874) * CREATE VIEW did not always succeed when the body of the view definition contained a join and multiple subselects. (Bug #30309982) References: This issue is a regression of: Bug #25466100. * Dependency information for SLES 12 RPM packages was incorrect, causing MySQL installation failure. (Bug #30308305) * When restoring GEOMETRY data from hash join chunk files to a GEOMETRY column, the server did not copy the data to the column, but instead stored a pointer to the data, which resided in a temporary buffer, meaning that the GEOMETRY column pointed to random data as soon as this buffer was reused. Now, the server always copies the data from this buffer into the GEOMETRY column when executing a hash join. (Bug #30306279) * Some ALTER TABLE operations using the COPY algorithm did not handle columns with expression default values properly. (Bug #30302907, Bug #96864) * The CONV() function did not always handle returning the proper number of characters correctly. (Bug #30301543) * Parser recursion checks were insufficient to prevent stack overflow. (Bug #30299881) * The removal of a subquery because the condition in which it occurred was always false was expected to be performed during resolution, but when the subquery did not involve any tables, the server executed it while resolving it. This resulted in the failure of a subsequent check to confirm that the subquery was only being resolved and not yet optimized. Now in such cases, the server also checks to see whether the subquery was already executed. (Bug #30273827) * For debug builds, attempts to add to an empty temporary table a column with an expression default that was not valid raised an assertion. (Bug #30271792) * Construction of the iterator tree may yield a non-hierarchical structure; this can happen when, for example, b and c from a LEFT JOIN b LEFT JOIN c also make up the right side of a semijoin. The iterator executor solves this by adding a weedout on top of the entire query, which means that is is also necessary to iterators interacting with row IDs that they need to store and restore them. This was not done in all such cases, causing wrong results. Now the addition of a top-level weedout is always communicated to the iterators as soon as it is known that this is being done, before any affected iterators are constructed. (Bug #30267889) * Foreign key-handling code duplication between the SQL layer and the data dictionary was eliminated. A side effect is that some error messages now are more informative and clear. (Bug #30267236, Bug #96765) * During startup, the server could handle incorrect option values for persisted variables improperly, resulting in a server exit. (Bug #30263773) * In some queries involving materialized semijoins, when using the iterator executor, conditions were evaluated outside the materialization, causing inefficient query plans to be used and sometimes also producing wrong results. (Bug #30250091) * ALTER TABLE statements that renamed a column used in CHECK constraints could result in an incorrect error message. (Bug #30239721) * For SELECT statements, an INTO var_name clause prior to a locking clause is legal but the parser rejected it. (Bug #30237291, Bug #96677) * FLUSH TABLES WITH READ LOCK caused a deadlock when a LOCK INSTANCE FOR BACKUP statement was previously executed within the same session and there was a concurrent ALTER DATABASE statement running in another session against the same database specified (implicitly or explicitly) for the FLUSH TABLES WITH READ LOCK statement. (Bug #30226264) * Slow query logging could result in a server exit for connections that did not use the classic client/server protocol. (Bug #30221187) * A statement that added a foreign key without an explicit name failed when re-executed as a prepared statement or in a stored program with an unwarranted duplicate foreign key name error. (Bug #30214965, Bug #96611) References: This issue is a regression of: Bug #30171959. * With multiple sessions executing concurrent INSERT ... ON DUPLICATE KEY UPDATE statements into a table with an AUTO_INCREMENT column but not specifying the AUTO_INCREMENT value, inserts could fail with a unique index violation. (Bug #30194841, Bug #96578) * Client programs could load authentication plugins from outside the plugin library. (Bug #30191834) * When switching between table scans and index lookups, AlternativeIterator did not reset the handler, which could lead to assertion failures. (Bug #30191394) * Setting open_files_limit to a large value, or setting it when the operating system rlimit had a value that was large but not equal to RLIM_INF could cause the server to run out of memory. As part of this fix, the server now caps the effective open_files_limit value to the the maximum unsigned integer value. (Bug #30183865, Bug #96525) * References to fully qualified INFORMATION_SCHEMA tables could fail depending on the lettercase in which INFORMATION_SCHEMA was specified. (Bug #30158484) * Slow queries with an execution time greater than 35 days could cause corruption of the mysql.slow_log system table requiring a REPAIR TABLE operation. (Bug #30113119, Bug #96373) * MySQL did not support sending systemd notification messages to a socket specified using the NOTIFY_SOCKET environment variable, if the variable named an abstract namespace socket. (Bug #30102279) * Using SET PERSIST_ONLY to set a boolean system variable to a numeric value resulted in the server being unable to restart. (Bug #30094645, Bug #30298191, Bug #96848) * A fix for a previous issue combined two TABLE_LIST constructors in an unfortunate way. One of these created a TABLE_LIST object from a TABLE object representing a temporary table. Previously, the table name was made the same as the alias; this was changed to copying the name from the TABLE object. Due to the fact that, for a temporary table, the table name is a file path, it was possible to exceed the limit for MDL_key names, leading to a failed assertion. Fixed by reintroducing dedicated constructors which behave in the manner that they did prior to the fix. (Bug #30083125) References: This issue is a regression of: Bug #27482976. * For UNIX_TIMESTAMP() errors occurring within stored functions, the number of fractional seconds for subsequent function invocations could be incorrect. (Bug #30034972, Bug #96166) * When a common table expression contained a nondeterministic expression (such one that used RAND()) and the common table expression was referenced more than once in the outer query, it was merged in some cases. This caused the common table expression to return a different result for each reference. Now in such cases, the common table expression is not merged, but rather is materialized instead. (Bug #30026353) * In debug build of MySQL started on Linux with a lower_case_table_names=1 setting, discarding a tablespace for a partitioned table after an in-place upgrade from MySQL 8.0.16 caused a serious error. The partition tablespace name stored in the data dictionary was invalid, and the metadata lock key prepared for the partition tablespace in MySQL 8.0.17 did not match the key stored in the mysql.tablespaces table. (Bug #30024653) * KILL QUERY could kill the statement subsequent to the one intended. (Bug #29969769) * With lower_case_table_names=2, SHOW TABLES could fail to display tables with uppercase names. (Bug #29957361) * The error message reported when attempting to upgrade tables with invalid expressions for generated columns did not provided sufficient information. The error message now includes the generated column name and the expression used to create the generated column. (Bug #29941887, Bug #95918) * Attempting to display an unresolvable view could result in a server exit rather than an error. (Bug #29939279) * Incorrect checking of temporal literals for CREATE TABLE statements could lead to a server exit. (Bug #29906966, Bug #95794) * Writing unexpected values to the mysql.global_grants system table could cause a server exit. (Bug #29873343) * The LAST_EXECUTED value in the INFORMATION_SCHEMA.EVENTS table was incorrectly reported in UTC, not in the event time zone. (Bug #29871530, Bug #95649) * With keyring_encrypted_file_password set on the command line at server startup, the password value could be visible to system utilities. (Bug #29848634) * Changing the lower_case_table_name setting when upgrading from MySQL 5.7 to MySQL 8.0 could cause a failure due to a schema or table name lettercase mismatch. If lower_case_table_names=1, table and schema names are now checked by the upgrade process to ensure that all characters are lowercase. If table or schema names are found to contain uppercase characters, the upgrade process fails with an error. For related information, see Preparing Your Installation for Upgrade (https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html). (Bug #29842749, Bug #95559) * Attempting to spawn a thread for a parallel read operation while system resources were temporary unavailable raised system error. (Bug #29842749, Bug #95559) * With a LOCK TABLES statement in effect, a metadata change for the locked table could cause Performance Schema or SHOW queries for session variables to hang in the opening_tables state. (Bug #29836204, Bug #92387) * A SELECT using a WHERE condition of the form A AND (B OR C [OR ...]) resulting in an impossible range led to an unplanned exit of the server. (Bug #29770705) * For JSON-format audit logging, the id field now may contain values larger than 65535. Previously, with heaving logging activity, more than 65536 queries per second could be executed, exceeding the 16 bits permitted for id values. (Bug #29661920) * An incomplete connection packet could cause clients not to properly initialize the authentication plugin name. (Bug #29630767) * Out-of-memory errors from the parser could be ignored, resulting in a server exit. (Bug #29614521) * On Linux, an assertion could be raised when the Performance Schema file instrumentation was disabled and re-enabled. (Bug #29607570) * For a column defined as a PRIMARY KEY in a CREATE TABLE statement, a default value given as an expression was ignored. (Bug #29596969, Bug #94668) * The TABLE_ENCRYPTION_ADMIN privilege, added in MySQL 8.0.16, was incorrectly granted to the system-defined mysql.session user during upgrade. (Bug #29596053, Bug #94888) * For connections encrypted with OpenSSL, network I/O at the socket level was not reported by the Performance Schema. Also, network I/O performed while the server was in an IDLE state was not reported by the Performance Schema. (Bug #29205129, Bug #30535558, Bug #97600) * When a query used a subquery that was merged into the outer query block (due to a semijoin transformation or merge of a derived table), and the subquery itself contained a subquery with an aggregate function with an aggregation query block that differed from its base query block, the query could sometimes fail to return any rows unless executed a second time or preceded with FLUSH TABLES. This was because, when merging, the information regarded tables used and the aggregation information for the aggregate function was not updated properly. In the case which raised this bug report, this meant that the comparison operation containing a scalar subquery was regarded as const-for-execution and therefore the range optimizer attempted to evaluate it, and the scalar subquery contained a MIN() function referring to an outer reference which had not yet been read. Thus, when the aggregator object was populated, it was based on uninitialized data, leading to unpredictable results. (Bug #28941154) * Changing the mandatory_roles system variable could cause SHOW GRANTS in concurrent sessions to produce incorrect results. (Bug #28699403) * Failure of keyring_aws initialization caused failure of SSL socket initialization. (Bug #28591098) * Under certain conditions, enabling the read_only or super_read_only system variable did not block concurrent DDL statements executed by users without the SUPER privilege. (Bug #28438114, Bug #91852) * For slow query logging, the Slow_queries was not implemented unless the slow query log was enabled, contrary to the documentation. (Bug #28268680, Bug #91496) * The current GROUP BY plan is improved so that every gap attribute is allowed to have a disjunction of equality predicates. Predicates from different attributes must still be conjunctive to each other in order to take advantage of this enhancement. Our thanks to Facebook for this contribution. (Bug #28056998, Bug #15947433) * In some cases, BIGINT arguments to the FLOOR() and CEILING() functions were resolved as the wrong type. (Bug #27125612) * mysqlpump exits rather than dumping databases that contain an invalid view, by design, but it also failed if an invalid view existed but was not in any of the databases to be dumped. (Bug #27096081) * Foreign key information is now retrieved from the data dictionary, not from InnoDB. (Bug #25583288) * Foreign key definitions used in CREATE TABLE and ALTER TABLE statements for InnoDB tables were ignored if the statements were wrapped in conditional comments (such as /*!50101 ... */ or /*! ... */). (Bug #21919887, Bug #78631) * The --log-raw option is now available at runtime as the log_raw system variable. The system variable is set at startup to the option value, and may be set at runtime to change password masking behavior. (Bug #16636373, Bug #68936) * EXPLAIN ANALYZE did not execute subqueries in the SELECT list, and thus did not take them into account in its calculations of time or cost. (Bug #97296, Bug #30444266) * An inner scalar subquery containing an outer reference did not return the same result using a nested set of SELECT expressions on the right hand side as when using a single SELECT that was equivalent. (Bug #97063, Bug #30381092) * A materialized subquery could yield different results depending on whether it used an index. (Bug #96823, Bug #30289052) * When a query terminated due to exceeding the time specified using the MAX_EXECUTION_TIME hint, the error produced differed depending on the stage of the query. In particular, if the query terminated during a filesort, the error raised was ER_FILSORT_ABORT, even though in such cases the query should always exit with ER_QUERY_TIMEOUT. This made it unnecessarily difficult to trap such errors and to handle them correctly. This fix removes the error codes ER_FILSORT_ABORT and ER_FILESORT_TERMINATED. (Bug #96577, Bug #30186874) * If a stored procedure had a parameter named member or array, and it had been defined without quoting the parameter names, the database in which it was defined could not be upgraded to 8.0.17 or 8.0.18. (Bug #96288, Bug #30084237) References: See also: Bug #96350, Bug #30103640. * When a function such as COALESCE() or IFNULL() was passed a BIGINT column value, casting a negative return value from this function to UNSIGNED unexpectedly yielded zero. Our thanks to Oleksandr Peresypkin for this contribution. (Bug #95954, Bug #29952066) * EXPLAIN output showed Select tables optimized away for a query using MAX() on an indexed column, but if MAX() on the same column was called in a user function, it showed Using index instead. (Bug #94862, Bug #29596977)
Edited 1 time(s). Last edit at 01/13/2020 07:03AM by Bjørn Munch.
MySQL Community Server 8.0.19 has been released, part 2/2
January 13, 2020 06:59AM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.