MySQL Community Server 8.0.22 has been released (part 2/2)
Posted by: Bjørn Munch
Date: October 19, 2020 08:06AM
Date: October 19, 2020 08:06AM
[ This is part 2 of the annopuncement]
Bugs 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.
Thanks to Krunal Bauskar for the contribution. (Bug
#31589019, Bug #100132)
* 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.
Thanks to TXSQL (Tencent MySQL) for the contribution.
(Bug #30933728, Bug #31228694)
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.
Thanks to Kamil Holubicki for the contribution. (Bug
#30607708)
* 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;
(Bug #31446381, Bug #99778)
* 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 ();
(Bug #15988466, Bug #67863)
* 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)
References: This issue is a regression of: Bug #80244,
Bug #22661012.
* 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)
Subject
Views
Written By
Posted
MySQL Community Server 8.0.22 has been released (part 2/2)
2974
October 19, 2020 08:06AM
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.