MySQL 歷史版本列表 Page15

更新時間：2020-11-04
更新細節：

What's new in this version:

- Support for minor Chromium upgrade （86.0.4240.111 → 86.0.4240.183)
- Remove the weather forecast from the new tab page

更新時間：2020-11-03
更新細節：

更新時間：2020-10-28
更新細節：

What's new in this version:

- Fixes a crash that could occur when changing the configuration of SDI output devices
- Fixes a crash that can occur when starting NDI outputs
- Fixes a bug with selecting slides using the shift modifier key resulting in an incorrect selection
- Fixes a bug with pasted media actions not retaining the set effect parameters
- Fixes an issue with the spacebar not working while the media store is open
- Fixes an issue where audio files do not respect the set out point
- Fixes a bug that causes playlist migrations from ProPresenter 6 to not populate linked presentations
- Fixes a bug that causes the linked text highlight to render on slide image exports
- Fixes an issue with effect presets not unlinking properly in the media inspector
- Fixes a bug that causes media thumbnails to not update for overwritten media until ProPresenter is restarted
- Fixes a bug where timer action settings do not save automatically
- Fixes an issue with text deleting when the tab key is pressed while the advanced color options are open
- Fixes a bug with presentations not importing if the presentation has a period in the filename
- Fixes a bug that cases the timer window to not work when ProPresenter Remote is connected
- Fixes a bug with custom shapes having stroke enabled by default
- Fixes a bug that causes the search window to intermittently appear behind the main application interface

更新時間：2020-10-21
更新細節：

What's new in this version:

- Support for minor Chromium upgrade （86.0.4240.75 → 86.0.4240.111)

更新時間：2020-10-20
更新細節：

更新時間：2020-10-20
更新細節：

更新時間：2020-10-19
更新細節：

What's new in this version:

Fixed:
- InnoDB: Code related to transaction support for histogram sampling was removed, including related assertion code that caused test failures. Transaction support is not required for histogram sampling. (Bug #31787736)
- InnoDB: Encryption information was not set for redo log archive log writer thread write operations. (Bug #31690196)
- InnoDB: The TTASEventMutex::exit function was optimized for ARM64
- InnoDB: InnoDB failed to compile with the DISABLE_PSI_RWLOCK CMake option enabled. (Bug #31578289)
- InnoDB: The transaction isolation level, which is set to READ UNCOMMITTED for histogram sampling to avoid unnecessary lookups of old record versions, was not reset after the sampling operation completed. (Bug #31564407)
- InnoDB: A query that updated the clustered index of an internal temporary table returned an incorrect result. The modified pages of the clustered index were not added to the flush list resulting in lost changes when the modified pages were evicted from the buffer pool. (Bug #31560679)
- References: This issue is a regression of: Bug #29207450.
- InnoDB: A build dependency on the Boost library defined for the TempTable storage engine was removed. (Bug #31505048)
- InnoDB: A workaround was implemented to handle a Clang compiler issue in 32-bit builds that causes the ATOMIC_LLONG_LOCK_FREE value to be defined as “sometimes lock-free” while __atomic_always_lock_free returns true for the same type on the same platform. (Bug #31504609)
- InnoDB: A REDUNDANT row format table created in an earlier version of MySQL, where the row format was not defined explicitly, permitted the addition of an index that exceeded the REDUNDANT row format index column size limit. (Bug #31479542, Bug #99791)
- InnoDB: A DML operation on a column defined with a multi-valued index caused a failure. (Bug #31479282)
- InnoDB: A failure occurred during master key rotation. An undo tablespace in-memory object was freed prematurely. (Bug #31467626)
- InnoDB: Unused physical read ahead code was removed from the parallel read interface. (Bug #31429385)
- InnoDB: A master key rotation operation failed to skip an undo tablespace that was already truncated, which lead to an assertion failure when shutting down the server. (Bug #31400195)
- InnoDB: After importing a tablespace for a page-compressed table, pages were no longer compressed, and INFORMATION_SCHEMA.INNODB_TABLESPACES metadata incorrectly indicated that pages were compressed. The table's compression information was unavailable during the import operation. (Bug #31396947)
- InnoDB: A rollback and update operation after performing an instant DDL operation raised an assertion. (Bug #31391126)
- InnoDB: The log system (log_sys) sharded read-write lock caused a performance regression in CPU-bound workloads. (Bug #31389135)
- InnoDB: Compiling with the UNIV_ENCRYPT_DEBUG option enabled caused compilation errors. (Bug #31369540)
- InnoDB: DDL operations on a partitioned table could cause a failure. TABLE_SHARE and table instance objects were opened for all partitions unnecessarily. (Bug #31365127)
- InnoDB: After changing a VARCHAR column collation from utf8mb4 to utf8mb4_bin in an in-place ALTER TABLE operation and adding an index on the same column, a case-sensitive query on the VARCHAR column returned an incorrect result. The VARCHAR column collation was changed in the data dictionary but not in the in-memory table object. Consequently, the index created on the VARCHAR column used stale column information causing comparisons to use the previously defined collation. (Bug #31361838)
- InnoDB: An ALTER TABLE ... IMPORT TABLESPACE operation on a large encrypted and compressed table failed with a Page decompress failed after reading from disk error. The decryption operation did not use the encryption block size used during encryption. Also, the encryption process did not consider compressed length, while the decryption process decrypts data by compressed length only. (Bug #31313533)
- InnoDB: A failure occurred during a concurrent update operation. The failure was due to an invalid previous record value. (Bug #31205266, Bug #99286)
- InnoDB: Upgrade from MySQL 5.7 to MySQL 8.0 failed on an instance with a table created in a general tablespace and defined with a FULLTEXT index. The correct data dictionary space ID for table could not determined. (Bug #31154128, Bug #99211)
- InnoDB: The function used to process the SHOW ENGINE INNODB MUTEX statement was insufficiently isolated from other threads adding new mutexes concurrently. (Bug #31105262)
- InnoDB: Failure to call a buffer pool page I/O completion routine resulted in orphan buffer pool I/O write pages. (Bug #31073853)
- InnoDB: Numerous system temporary table pages at the tail of the buffer pool flush list caused a performance degradation. The flush_list_mutex was held while the flush list scan traversed over system temporary table pages. The flush list scan now excludes system temporary table pages. (Bug #31060470, Bug #98974)
- InnoDB: The buffer control block structure (buf_block_t) was freed while reducing the size of the buffer pool, causing an assertion failure. The fix for this bug also backports important aspects of the fix for Bug #20735882 / Bug #76343, and replaces the internal buf_block_is_uncompressed() function with the buf_pointer_is_block_field_instance() function. The buf_block_is_uncompressed() function returned false in too many cases, affecting OLTP query throughput. (Bug #31036301, Bug #31389823)
- InnoDB: Parallel read threads failed to respond to an explicit transaction interruption. (Bug #31016076)
- InnoDB: In session started with START TRANSACTION WITH CONSISTENT SNAPSHOT, a range query returned a truncated result. The end range flag was not reset at the beginning of the index read resulting in an aborted read and missing rows. (Bug #30950714, Bug #98642)
- References: This issue is a regression of: Bug #23481444.
- InnoDB: A full-text phrase search raised an assertion failure.
- References: This issue is a regression of: Bug #22709692.
- InnoDB: A failure occurred while attempting to initialize the system tablespace on a raw disk partition. Additionally, a INPLACE DDL operation on the raw-disk partition tablespace failed with an error instead of switching to the COPY algorithm. (Bug #30867065, Bug #98091)
- InnoDB: LOB purge code (lob::purge()) did not properly handle latches taken during B-tree mini-transaction (btr_mtr) commit and restore operations, which could lead to conflicts between B-tree and LOB mini-transactions. (Bug #30620011)
- InnoDB: A long running statistics calculation operation on a large table blocked other operations requiring access to the table's statistics, causing those operations to fail. A new statistics calculation mutex was introduced, which permits concurrent access table statistics.
- InnoDB: Two connections attempted to use the same transaction handler object resulting in a stalled query. (Bug #30594501)
- InnoDB: Shutting down the server with innodb_fast_shutdown setting greater than 0 raised an assertion failure. The assertion was caused by the presence of recovered transactions that were not yet rolled back. Assertion code was revised to ignore recovered transactions during a fast shutdown. Messages are now written to the error log when recovered transactions that are not rolled back are left behind by a fast shutdown. Slow shutdown now waits for recovered transactions to be rolled back. Various other shutdown logic improvements were implemented. (Bug #30226841)
- InnoDB: Dedicated log writer threads, introduced in MySQL 8.0.11, caused a CPU-bound performance regression on low-concurrency systems. To address this issue, the new innodb_log_writer_threads variable permits disabling dedicated log writer threads so that redo log records are written from the log buffer to the system buffers and flushed from the system buffers to the redo log files by each user thread, which is the behavior prior to the introduction of dedicated log writer threads. Other redo logging optimizations were implemented, including the removal of an unnecessary log closer thread that wasted CPU time, and optimizations to remedy too-aggressive checkpoint activity and excessive flush calls. The issues addressed by this fix also manifested in a LOAD DATA performance regression. (Bug #30088404, Bug #30003849)
- InnoDB: Restarting the server with an incorrect lower_case_table_names setting after a failure caused a hang condition. At startup, InnoDB waited for a transaction to roll back, but the rollback thread was not initiated due to a startup validation failure caused by the incorrect lower_case_table_names setting. (Bug #29833945)
- Replication: X Plugin could stop unexpectedly if a Group Replication notification was issued after a new X Protocol connection was made but before the session was created. The dispatcher thread that handles Group Replication notifications now checks that the session pointer is valid. (Bug #31742798)
- Replication: Group Replication's handling of memory allocation issues when adding transaction write sets has been improved. (Bug #31586243)
- Replication: You can now set the value of the gtid_purged system variable in a stored procedure, which was not previously permitted. You cannot set gtid_purged in a stored function. (Bug #31571427)
- Replication: While a remote cloning procedure was taking place on a joining member during distributed recovery, Group Replication considered the pre-cloning gtid_executed value of the joining member when identifying the common set of transactions that had been applied on all members. This meant that garbage collection for applied transactions from the group's set of certification information (shown as the count_transactions_rows_validating field in the Performance Schema table replication_group_member_stats) did not take place during the remote cloning procedure. If the remote cloning procedure took a long time, the certification information could therefore get too large to transmit to the joining member when it restarted after the remote cloning procedure, in which case an error was raised and the member was not able to join the group.
- To avoid this issue, Group Replication now considers only group members with ONLINE status when identifying the common set of transactions that have been applied on all members. When a joining member enters ONLINE state after distributed recovery, its certification information is updated with the certification information from the donor at the time when the member joined, and garbage collection takes place for this on future rounds.
- As a workaround for this issue in earlier releases, after the remote cloning operation completes, wait two minutes to allow a round of garbage collection to take place to reduce the size of the group's certification information. Then issue the following statement on the joining member, so that it stops trying to apply the previous set of certification information:
- RESET SLAVE FOR CHANNEL group_replication_recovery;
- Replication: It was possible for a group member that left the group due to a communication error to reconnect between auto-rejoin attempts while the auto-rejoin procedure was still ongoing, which left Group Replication unable to function on the member. Group Replication's error management and member status handling has now been corrected to prevent this situation. (Bug #31401797)
- Replication: When a replication source server shuts down and restarts, its MEMORY tables become empty. To replicate this effect to replicas, the first time that the source uses a given MEMORY table after startup, it logs an event that notifies replicas that the table must be emptied by writing a statement to the binary log to that effect. Previously, this was a DELETE statement, but it is now a TRUNCATE TABLE statement. A replica server also writes this statement to its own binary log when it shuts down and restarts. The statement is always logged in statement format, even if the binary logging format is set to ROW, and it is written even if read_only or super_read_only mode is set on the server. (Bug #29848785, Bug #95496)
- Replication: When the system variable session_track_gtids was set to OWN_GTID on a multithreaded replica, the replica’s performance would degrade over time and begin to lag behind the master. The cause was the buildup of the GTIDs recorded by the replica’s worker threads at each transaction commit, which increased the time taken by the worker threads to insert new ones. Session state tracking is now disabled for worker threads on a multithreaded replica. Thanks to Facebook for the contribution. (Bug #29049207, Bug #92964)
- Replication: When using row-based replication, the replica was allowed to use an invisible index when searching for rows to synchronize. (Bug #96148, Bug #30072179)
- Microsoft Windows: On Windows, build targets could fail if the build was on a file system root, such as R:/. (Bug #31315467)
- JSON: JSON_ARRAYAGG() did not always perform proper error handling. (Bug #31856260)
- JSON: JSON_OBJECT() did not always perform proper checking for NULL values. (Bug #31393934)
- The new WITH_SYSTEMD_DEBUG CMake option, if enabled, produces additional systemd debugging information, for platforms on which systemd is used to run MySQL. The default is OFF. (Bug #31788834)
- For RPM and Debian packages, client-side plugins were moved from the server package to the client package in MySQL 8.0.21. This could cause failures relating to LDAP authentication plugins when upgrading from 5.7 packages to 8.0 packages. Packaging adjustments were made to avoid this problem. (Bug #31782612)
- References: This issue is a regression of: Bug #31123564, Bug #31336340.
- The timestamp written for the ts key by the log_sink_json JSON-format error log sink did not have the same value as other timestamps in the same log message. (Bug #31749103)
- Kerberos authentication for the SASL LDAP authentication plugin incorrectly handled failure to acquire a ticket-granting ticket. (Bug #31727195)
- For some third-party libraries, enabling link-time optimization caused build failures. (Bug #31701553, Bug #100410)
- Printing an excessively long diagnostic message could cause the server to exit unexpectedly. (Bug #31686926)
- A page-compressed table was cloned as an uncompressed table. The associated tablespace object, which includes a compression flag, was not initialized prior to the cloning operation. (Bug #31677990, Bug #100243)
- Certain cases of successful LDAP authentication could cause the server to hang. (Bug #31661437)
- During transformation of a grouped query into a derived table, when the WHERE clause and the HAVING clause became part of the derived table, the condition count was not updated for the derived table. This resulted in reduced memory allocation while creating keys for ref access. (Bug #31661309)
- When a value was compared using LIKE with a table column not defined as one of the MySQL string types, the server sometimes did not raise the expected error. (Bug #31659015)
- The acquire_related() service function returned the default service in some cases when it should have returned an error. (Bug #31655906)
- In bootstrapping mode, certain multiple-statement transactions could cause unexpected server behavior. (Bug #31650096)
- A remote cloning operation checked for the availability of a plugin on the recipient that was removed from the donor instance previously. References to the uninstalled plugin had not been released. Error reporting issues related to plugin mismatches and availability were also addressed. (Bug #31639732, Bug #100244)
- MySQL Server Docker images did not expose the Group Replication recommended port (33061). (Bug #31627536)
- In debug builds, the server attempted to evaluate subqueries while creating a view. (Bug #31590301)
- References: This issue is a regression of: Bug #25466100.
- A condition using RAND() was not pushed down even in cases where it was safe to do so, that is when no windowing function or GROUP BY is in use. (Bug #31587575)
- While pushing conditions down to a derived table, a constant condition such as WHERE FALSE or WHERE TRUE was pushed down to the first table in the derived table, which is not necessary as the condition has nothing to do with the derived table. MySQL now avoids pushing constant conditions down to derived tables in such cases.
- In addition used tables are now updated for the condition that needs to be pushed down to the derived table, following code inspection revealing that this was not done after replacing the columns in the condition with the derived table expressions. (Bug #31587493)
- A query using WHERE column > (... IN (SELECT ...)) could sometimes trigger an assertion in the range optimizer. (Bug #31586906)
- References: This issue is a regression of: Bug #30473261.
- It was possible for ANALYZE TABLE to fail with Duplicate key error if a row was inserted in the interval between the check for the existence of the row and the execution of the insert, and the statistics table was updated concurrently. ANALYZE TABLE now ignores the error in this situation. (Bug #31582758)
- The range optimizer does not use the correct lock type after cloning the handler needed to perform merged scans, and instead used a read lock unconditionally. This resulted in various different side effects for different scenarios.
- For example, a SELECT with FOR UPDATE requests a write lock, but after cloning the handler for an index merge scan, the range optimizer requested a read lock which resulted in a mismatch. Similarly, for data dictionary tables, the lock type was set to LOCK_NONE due to the special handling required for such tables.
- To prevent this problem from occurring, we now ensure that the original lock type of the handler is always used in the cloned handler as well. (Bug #31582383)
- In some cases, a query using an ANY subquery gave an incorrect result when the subquery_to_derived optimizer switch was enabled. (Bug #31566339)
- When FALSE AND condition was simplified as FALSE, temporary table resources allocated for the condition were not always released afterwards. (Bug #31565009)
- A value equal to ULLONG_MAX could be inserted into a BIT(64) column, but not retrieved. (Bug #31564742, Bug #100053)
- While removing an unused window definition, a subquery that was part of an ORDER BY was not removed. The optimizer then tried to optimize the subquery without locking the tables. Now, when removing an unused window definition, the server cleans up any subqueries present as part of the definition. (Bug #31518806)
- References: This issue is a regression of: Bug #27062031.
- Added a missing error code translation from ICU U_REGEX_NUMBER_TOO_BIG to MySQL ER_REGEX_NUMBER_TOO_BIG. (Bug #31514995)
- Merging during filesort operations could fail to remove duplicates for queries that used DISTINCT. (Bug #31498664, Bug #99900)
- MySQL's internal DYNAMIC_STRING class formerly allocated memory in a linear fashion, that is, by a predetermined number of bytes. The class has been revised such that it now allocates memory exponentially, which should make operations such as repeated string appends more efficient. (Bug #31491799)
- LOCK_mutex mishandling could result in a memory leak. (Bug #31491146)
- A newly added collation was not added and could cause an unexpected exit on shutdown. (Bug #31470422)
- On Windows, file name reuse by the GetTempFileName() function could cause an assertion to be raised. (Bug #31468590)
- A LATERAL subquery was incorrectly converted into an antijoin. (Bug #31465717)
- NATURAL JOIN evaluation could inadvertently match hidden virtual columns created by functional indexes. (Bug #31463511, Bug #99807)
- Sort keys for string hash join keys using more than 1024 bytes were not handled correctly by the server. (Bug #31437753)
- The server attempted to delete from a view whose definition included HAVING when the HAVING clause was constant and evaluated as true even though a view with HAVING as part of its definition should not be updatable. (Bug #31429865)
- Privilege requirements were checked incorrectly for the INFORMATION_SCHEMA.USER_ATTRIBUTES table. (Bug #31427410)
- When the internal function replace_index_subquery() failed, the server still attempted to create iterators for the affected subquery. Now the function raises a clear error instead. (Bug #31427072)
- A query using WHERE NOT EXISTS (SELECT const FROM table WHERE column=FROM_UNIXTIME(value) was not handled correctly. (Bug #31425664)
- In some cases, key_hint handling was improperly applied to derived and internal temporary tables. (Bug #31424455)
- Re-execution of prepared INSERT statements could fail for inserts through a view. (Bug #31417951)
- JSON scalar evaluation could enter an infinite loop. (Bug #31406724)
- The user_attributes column in mysql.user table rows could be affected incorrectly by partial revokes. (Bug #31405985)
- Improper window function initialization could cause a server exit. (Bug #31389573, Bug #31437834)
- Sensitive LDAP authentication plugin system variables now display as asterisks when retrieved in SQL statements. (Bug #31388444, Bug #31391864)
- mysql-test-run.pl tests under no-threads connection handling failed with ASAN builds due to improper resource group initialization. This has been fixed. Thanks to Xiaoyu Wang, Tencent Technology for the contribution. (Bug #31378900, Bug #99609)
- Using the authentication_ldap_simple authentication plugin with SSL could cause a segmentation fault during shutdown. (Bug #31364927)
- Killing a query could raise spurious assertions in the hash join iterator. (Bug #31361354)
- In some cases, an outer reference that was not LATERAL was not marked as read-only as expected. (Bug #31359965)
- A failure occurred when upgrading from MySQL 5.7 to MySQL 8.0 due to invalid references to orphaned events (events for which a database no longer exists). The server now fails with an appropriate error messages when orphaned events are encountered during upgrade. Error messages for orphaned stored routines were also revised. (Bug #31335554)
- Enabling the create_admin_listener_thread system variable could cause a server exit during startup. (Bug #31335279)
- After ALTER TABLE to add an expression default to a column, the first insert inserted a value as if the expression had been evaluated at alter time and not insert time. (Bug #31330789, Bug #99513)
- The LDAP authentication plugins did not properly compare the user-supplied authentication method against the permitted methods. (Bug #31320532)
- Certain views could cause a following USE statement to result in an unexpected server exit. (Bug #31311312)
- When a filesort sorted a buffer and LIMIT was active, it first sorted all rows and then discarded those that did not fit within the limit, which required sorting many rows that were certain to be discarded later. Now the optimizer sorts only the rows actually needed. Internal testing shows that this change can speed up the sort phase for a simple string sorting benchmark (as measured by EXPLAIN ANALYZE) by up to 15%. (Bug #31303537)
- A dynamic range scan runs the range optimizer for each row fetched from the first table in a join to determine whether a range scan can be picked for the second table using the value available from that row. If the row contains no usable indexes, a table scan may be chosen instead. For the query giving rise to this issue, a table scan is chosen once, followed by a range scan on a non-covering index, and the dynamic range iterator has two read sets which are used for both these cases. One of these, used for the table scan, includes the base columns of generated columns required for processing the query; the other read set does not include the base columns in the read set used for range scans. This is because, for covering indexes, the read set should not include base columns to avoid adding unneeded columns by hash join or batched key access. The issue arose because the second read set was also used for a non-covering index, which resulted in an assert.
- To prevent this from happening, when initializing a table read set in the dynamic range iterator, we now make sure that it includes the base columns when the range optimizer picks a non-covering index. (Bug #31280526)
- References: This issue is a regression of: Bug #30417361.
- It was possible to insert an out-of-range value for a TIMESTAMP if it included a timezone offset. (Bug #31239157)
- The keyring_hashicorp keyring plugin did not limit the size of keys for key operations. (Bug #31205715)
- Configuring with -DWITH_ZSTD=system failed for older versions of the zstd library. CMake now checks the zstd version and requires at least 1.0.0 for compilation, 1.2.0 to run compression checks. (Bug #31174920, Bug #99241)
- In some cases, a SELECT that obtained status variable information from Performance Schema tables and that included a sort by a column containing temporal values was not handled correctly. (Bug #31168097)
- In some cases, ROUND() and TRUNCATE() did not return the data type of their first arguments as expected. This fix insures that return types from these functions follow these rules, where the first argument is of the type shown:
- For any integer type, the return type is BIGINT.
- For any floating-point type or any non-numeric type, the return type is DOUBLE.
- For DECIMAL, the return type is also DECIMAL.
- The type attributes for the return value are also copied from the first argument, except in the case of DECIMAL, when the second argument is a constant value.
- When the desired number of decimal places is less than the scale of the argument, the scale and the precision of the result are adjusted accordingly. In addition, for the ROUND() function, the precision is extended by one place to accomodate rounding that increases the number of significant digits. If the second argument is negative, the return type is adjusted such that its scale is 0, with a corresponding precision.
- For more information, see the description of the ROUND() function. (Bug #31128028)
- A SELECT ... FOR SHARE statement now only requires the SELECT privilege. Previously, the SELECT privilege was required with at least one of the DELETE, LOCK TABLES, or UPDATE privileges. (Bug #31096384, Bug #99101)
- A semijoin strategy was chosen for the join of a correlated subquery having a LIMIT clause and requiring a row other than the first, which caused the LIMIT clause to be ignored and invalid rows to be returned. Now, when LIMIT used with this type of join specifies a row other than the first row, or more than one row, the semijoin strategy is no longer employed. (Bug #31096309)
- After the fix for Bug #81009, privilege checks for truncating Performance Schema tables were too restrictive when read_only or super_read_only were enabled, causing truncation to fail even for users with appropriate table privileges. (Bug #31080309, Bug #99072)
- References: This issue is a regression of: Bug #81009.
- ORDER BY did not work as expected for queries with ROLLUP in which window functions were also used. (Bug #31073133)
- Some INSERT statements were not handled correctly. (Bug #31072198)
- Date interval calculations checked for overflow but not underflow. Now they check for both. (Bug #31054071)
- Regular expression functions such as REGEXP_LIKE() yielded inconsistent results with binary string arguments. These functions now reject binary strings with an error. (Bug #31031886, Bug #98951, Bug #31031888, Bug #98950)
- If an XA prepared transaction rollback XID was incorrectly formatted, the transaction remained in recovered state for XA COMMIT and XA ROLLBACK statements (or raised an assertion for debug builds) rather that reporting an error. (Bug #31030205)
- Database-level privileges inherited through a role were not handled properly for database names that contained wildcard characters. (Bug #31013538, Bug #98876)
- When the --local option was given, mysqlimport mishandled the MYSQL_OPT_LOAD_DATA_LOCAL_DIR option for mysql_options() so that it had no effect. (Bug #31001550)
- Certain prepared statements could cause an unexpected server exit. (Bug #30943963)
- OPTIMIZE TABLE for MyISAM tables could cause table size to increase and query performance to decrease. REPAIR TABLE for MyISAM tables could cause the Table is already up to date status produced by a previous OPTIMIZE TABLE to be lost. (Bug #30869674, Bug #98511, Bug #29755517)
- mysqlpump object validation included objects in excluded databases. (Bug #30819012)
- Inserting a TIMESTAMP value having a timezone offset which also had a zero for the month, day, or both, led to an assert. Such a value should be and is now rejected, regardless of the sql_mode setting. (Bug #30786762)
- References: See also: Bug #31239157.
- Comparison of a TIME value with NULL in some cases raised an assertion. (Bug #30324587)
- References: This issue is a regression of: Bug #25949639.
- LDAP authentication plugins enforced CA verification incorrectly, which could result in use of an incorrect CA. (Bug #30220357)
- ORDER BY queries were not executed correctly when sort_buffer_size and max_sort_length were set to values which caused the internal limit on the maximum number of keys allowed per sort buffer to be set to 0. (Bug #30175483)
- A large number of nested arguments in full-text search query caused an error. (Bug #29929684)
- A potential misreporting of memory use by the Performance Schema has been corrected. (Bug #29912403)
- When explicit_defaults_for_timestamp was disabled and a NULL was inserted into a generated column declared as TIMESTAMP NOT NULL, the server would attempt to convert the inserted value to CURRENT_TIMESTAMP. Such an insertion is now rejected with ER_BAD_NULL_ERROR. (Bug #29449518)
- The SET_VAR hint did not accept a floating point value specified as a system variable setting. (Bug #29349748)
- Previously, when NULL was used as the format argument to STR_TO_DATE(), irrelevant warnings were printed. Now, when NULL is passed to it, the function returns NULL. (Bug #27265863)
- In some cases, incorrect use of IS NULL generated multiple warnings about invalid arguments. (Bug #27264652)
- Resolving an ORDER BY column that referred to a SELECT list column from a derived table was not performed correctly when executing certain prepared statements. (Bug #26808862)
- When using EXPLAIN on a multi-table UPDATE statement in which a generated column was referenced in a condition, the output always showed the table containing this column as being updated, whether the table was actually updated or not. (Bug #22671310)
- An assertion could be raised when the SQL layer passed incorrect information to InnoDB about the type of operation to be performed on a temporary table. (Bug #22503696)
- This construct works for base tables to insert a row using all default values but failed for views:
- INSERT INTO name () VALUES ();
- In some cases, the server issued an error when an invisible index was used in an index hint even when the use_invisible_indexes optimizer switch was not set to OFF. (Bug #100024, Bug #31550839)
- When range values specified in a predicate are not compatible with the data type of the column with which the values are compared, the range optimizer rounds off the range values and assigns certain flags so that it does not exclude rows that qualify for the range because of rounding. In the specific query that triggered the reported issue, a column named id of type INT was tested using id NOT IN (-0.1, 0.1), and the values being tested are rounded to integers, with the predicate thus being treated as NOT IN (0,0). The optimizer then treats this as the intervals id < 0 and 0 < id < 0, but in this case it also set a flag to a value that indicated that reads should begin following rows containing 0 for the value to be compared. Now in such cases, the flag is set in such a way that the values which have been rounded are treated correctly. (Bug #98826, Bug #30988735)
- For a view based on a join having an updatable part and one that was not, the error message generated when attempting to update a column of this view that was not updatable referenced the source table or view instead of the view actually named in the offending UPDATE statement. (Bug #80655, Bug #22891840)

更新時間：2020-10-19
更新細節：

更新時間：2020-10-19
更新細節：

What's new in this version:

Added or Changed:
- LOCK TABLES privilege checking for views was improved

Bugs Fixed:
- InnoDB: A query that updated the clustered index of an internal temporary table returned an incorrect result. The modified pages of the clustered index were not added to the flush list resulting in lost changes when the modified pages were evicted from the buffer pool
- InnoDB: An ALTER TABLE ... IMPORT TABLESPACE operation on a large encrypted and compressed table failed with a Page decompress failed after reading from disk error. The decryption operation did not use the encryption block size used during encryption. Also, the encryption process did not consider compressed length, while the decryption process decrypts data by compressed length only
- InnoDB: A failure occurred during a concurrent update operation. The failure was due to an invalid previous record value
- InnoDB: The function used to process the SHOW ENGINE INNODB MUTEX statement was insufficiently isolated from other threads adding new mutexes concurrently
- InnoDB: The buffer control block structure (buf_block_t) was freed while reducing the size of the buffer pool, causing an assertion failure. The fix for this bug also backports important aspects of the fix for Bug #20735882 / Bug #76343, and replaces the internal buf_block_is_uncompressed() function with the buf_pointer_is_block_field_instance() function. The buf_block_is_uncompressed() function returned false in too many cases, affecting OLTP query throughput
- InnoDB: In session started with START TRANSACTION WITH CONSISTENT SNAPSHOT, a range query returned a truncated result. The end range flag was not reset at the beginning of the index read resulting in an aborted read and missing rows.
- InnoDB: A full-text phrase search raised an assertion failure. Thanks to TXSQL (Tencent MySQL) for the contribution
- InnoDB: A long running statistics calculation operation on a large table blocked other operations requiring access to the table's statistics, causing those operations to fail. A new statistics calculation mutex was introduced, which permits concurrent access table statistics. Thanks to Kamil Holubicki for the contribution.
- InnoDB: Two connections attempted to use the same transaction handler object resulting in a stalled query
- Replication: When a replication source server shuts down and restarts, its MEMORY tables become empty. To replicate this effect to replicas, the first time that the source uses a given MEMORY table after startup, it logs an event that notifies replicas that the table must be emptied by writing a statement to the binary log to that effect. Previously, this was a DELETE statement, but it is now a TRUNCATE TABLE statement. A replica server also writes this statement to its own binary log when it shuts down and restarts. The statement is always logged in statement format, even if the binary logging format is set to ROW, and it is written even if read_only or super_read_only mode is set on the server.
- Replication: When the system variable session_track_gtids was set to OWN_GTID on a multithreaded replica, the replica’s performance would degrade over time and begin to lag behind the master. The cause was the buildup of the GTIDs recorded by the replica’s worker threads at each transaction commit, which increased the time taken by the worker threads to insert new ones. Session state tracking is now disabled for worker threads on a multithreaded replica. Thanks to Facebook for the contribution.
- Certain cases of successful LDAP authentication could cause the server to hang
- In bootstrapping mode, certain multiple-statement transactions could cause unexpected server behavior
- Sensitive LDAP authentication plugin system variables now display as asterisks when retrieved in SQL statements
- After the fix for Bug #81009, privilege checks for truncating Performance Schema tables were too restrictive when read_only or super_read_only were enabled, causing truncation to fail even for users with appropriate table privileges
- Some INSERT statements were not handled correctly
- Certain prepared statements could cause an unexpected server exit
- mysqlpump object validation included objects in excluded databases
- LDAP authentication plugins enforced CA verification incorrectly, which could result in use of an incorrect CA
- ORDER BY queries were not executed correctly when sort_buffer_size and max_sort_length were set to values which caused the internal limit on the maximum number of keys allowed per sort buffer to be set to 0.
- A large number of nested arguments in full-text search query caused an error
- When explicit_defaults_for_timestamp was disabled and a NULL was inserted into a generated column declared as TIMESTAMP NOT NULL, the server would attempt to convert the inserted value to CURRENT_TIMESTAMP. Such an insertion is now rejected with ER_BAD_NULL_ERROR.
- An assertion could be raised when the SQL layer passed incorrect information to InnoDB about the type of operation to be performed on a temporary table

更新時間：2020-10-16
更新細節：