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.
Subject
Views
Written By
Posted
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.