MySQL Community Server 8.0.18 has been released, part 1/2
Posted by: Bjørn Munch
Date: October 14, 2019 07:37AM
Date: October 14, 2019 07:37AM
[Due to size limitations, this announcement is split in two. This is part 1]
Dear MySQL users,
MySQL Server 8.0.18, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.18 is
recommended for use on production systems.
For an overview of what's new in MySQL 8.0, please see
http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html
For information on installing MySQL 8.0.18 on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/8.0/en/installing.html
MySQL Server 8.0.18 is available in source and binary form for a number of
platforms from our download pages at
http://dev.mysql.com/downloads/mysql/
MySQL Server 8.0.18 is also available from our repository for Linux
platforms, go here for details:
http://dev.mysql.com/downloads/repo/
Windows packages are available via the Installer for Windows:
http://dev.mysql.com/downloads/installer/
along with .ZIP (no-install) packages for more advanced needs.
8.0.18 also comes with a web installer as an alternative to the full
installer.
The web installer doesn't come bundled with any actual products
and instead relies on download-on-demand to fetch only the
products you choose to install. This makes the initial download
much smaller but increases install time as the individual products
will need to be downloaded.
We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:
http://bugs.mysql.com/report.php
The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.17. It may also be viewed
online at
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html
Enjoy!
Edited 1 time(s). Last edit at 10/14/2019 07:46AM by Bjørn Munch.
Dear MySQL users,
MySQL Server 8.0.18, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.18 is
recommended for use on production systems.
For an overview of what's new in MySQL 8.0, please see
http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html
For information on installing MySQL 8.0.18 on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/8.0/en/installing.html
MySQL Server 8.0.18 is available in source and binary form for a number of
platforms from our download pages at
http://dev.mysql.com/downloads/mysql/
MySQL Server 8.0.18 is also available from our repository for Linux
platforms, go here for details:
http://dev.mysql.com/downloads/repo/
Windows packages are available via the Installer for Windows:
http://dev.mysql.com/downloads/installer/
along with .ZIP (no-install) packages for more advanced needs.
8.0.18 also comes with a web installer as an alternative to the full
installer.
The web installer doesn't come bundled with any actual products
and instead relies on download-on-demand to fetch only the
products you choose to install. This makes the initial download
much smaller but increases install time as the individual products
will need to be downloaded.
We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:
http://bugs.mysql.com/report.php
The following link lists the changes in the MySQL 8.0 since
the release of MySQL 8.0.17. It may also be viewed
online at
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html
Enjoy!
Changes in MySQL 8.0.18 (2019-10-14)
* Account Management Notes
* Compilation Notes
* Configuration Notes
* Connection Control Notes
* Deprecation and Removal Notes
* Keyring Notes
* Logging Notes
* Optimizer Notes
* Packaging Notes
* Pluggable Authentication
* Spatial Data Support
* sys Schema Notes
* Test Suite Notes
* X Plugin Notes
* Functionality Added or Changed
* Bugs Fixed
Account Management Notes
* The CREATE USER, ALTER USER, and SET PASSWORD statements
now have the capability of generating random passwords
for user accounts, as an alternative to requiring
explicit administrator-specified literal passwords. See
Random Password Generation
(https://dev.mysql.com/doc/refman/8.0/en/password-management.html#random-password-generation).
Compilation Notes
* Incompatible Change: The my_ulonglong type is no longer
used in MySQL source code. Any third-party code that used
this type should use the uint64_t C type instead. Also,
it is possible that printf() format strings will need
adjustment if used to print my_ulonglong variables. (Bug
#29453827)
* The minimum version of the Boost library for server
builds is now 1.70.0. (Bug #29639344)
* A DBUG_TRACE macro is available to assist in writing
debug code. It is a convenience that replaces pairs of
enter/leave macros. For example, instead of writing this:
void foo() {
DBUG_ENTER("foo");
bar();
DBUG_VOID_RETURN;
}
Write this instead:
void foo() {
DBUG_TRACE;
bar();
}
(Bug #29589102)
Configuration Notes
* CMake now enables use of fastcov if it is available.
fastcov is faster than lcov or gcov. This requires GCC
and gcov versions of 9 or higher. (Bug #30011512)
* The DISABLE_SHARED CMake option was unused and has been
removed. (Bug #29971049, Bug #96027)
* The CMake code to find Protobuf executables now works on
platforms that split these into multiple packages. (Bug
#29953773)
* The new ADD_GDB_INDEX CMake option determines whether to
enable generation of a .gdb_index section in binaries,
which makes loading them in a debugger faster. The option
is disabled by default. It has no effect if a linker
other than lld or GNU gold is used. (Bug #29925009, Bug
#95857)
* For the INSTALL_LAYOUT CMake option, the SLES and WIN
option values were not used and have been removed. (Bug
#29871520, Bug #95654)
* The max_prepared_stmt_count system variable maximum value
has been increased from 1 million (1,048,576) to 4
million (4,194,304). The default value remains unchanged
at 16,382.
* MySQL 8.0 no longer supports building using wolfSSL. All
MySQL builds now use OpenSSL.
* The RE2 library is no longer used by MySQL. The library
is no longer bundled with source distributions and the
WITH_RE2 CMake option is obsolete.
Connection Control Notes
* MySQL now provides more control over the use of
compression to minimize the number of bytes sent over
connections to the server. Previously, a given connection
was either uncompressed or used the zlib compression
algorithm. Now, it is also possible to use the zstd
algorithm (zstd 1.3), and to select a compression level
for zstd connections. The permitted compression
algorithms can be configured on the server side, as well
as on the connection-origination side for connections by
client programs and by servers participating in
master/slave replication or Group Replication. For more
information, see Connection Compression Control
(https://dev.mysql.com/doc/refman/8.0/en/connection-compression-control.html).
Connection compression using the zstd algorithm requires
that the server be built with zstd library support. The
new WITH_ZSTD CMake option indicates whether to use the
bundled or system zstd library.
Legacy compression-control parameters, such as the
--compress client option, are deprecated and will be
removed in a future MySQL version.
Thanks to Facebook for a contribution on which some of
this work was based.
Deprecation and Removal Notes
* Use of the MYSQL_PWD environment variable to specify a
MySQL password is considered insecure because its value
may be visible to other system users. MYSQL_PWD is now
deprecated and support for it will be removed in a future
MySQL version.
Keyring Notes
* MySQL Enterprise Edition now includes a keyring_hashicorp
plugin that uses HashiCorp Vault as a back end for
keyring storage. For more information, see The MySQL
Keyring
(https://dev.mysql.com/doc/refman/8.0/en/keyring.html).
Logging Notes
* Log buffering during server startup was adjusted for less
delay in the appearance of output in the error log. (Bug
#30019632)
Optimizer Notes
* Queries involving first match split jump operations were
handled wrongly in the iterator executor. They are now
rewritten to weedout. (Bug #30220791)
* Hash joins have been implemented as a way of executing
inner equi-joins in MySQL. For example, a query such as
this one can be executed as a hash join beginning with
this release:
SELECT *
FROM t1
JOIN t2
ON t1.c1 = t2.c1;
Multi-table joins using equi-joins can also take
advantage of this optimization.
A hash join requires no index for execution. In most
cases, a hash join is more efficient than the
block-nested loop algorithm previously used for
equi-joins without indexes.
By default, beginning with this release, a hash join is
used whenever a join includes at least one equi-join
condition. This preference can be overridden by setting
the hash_join optimizer switch to off, or by using the
NO_HASH_JOIN optimizer hint. In addition, you can control
the amount of memory used by a hash join by setting
join_buffer_size. A join whose memory requirement exceeds
this amount is executed on disk; an on-disk hash join
uses a number of disk files and may not be executable if
this number exceeds open_files_limit.
A hash join cannot be employed if the join conditions for
any pair of joined tables do not include at least one
equi-join condition among all join conditions used. A
hash join is used for a Cartesian product---that is, a
join that specifies no join conditions at all.
You can see whether hash joins have been used to optimize
a query in the output of EXPLAIN FORMAT=TREE or EXPLAIN
ANALYZE.
For more information, see Hash Join Optimization
(https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html).
* Added EXPLAIN ANALYZE, which provides iterator-based
timing, cost, and other information about queries in TREE
format. This statement produces output similar to that of
EXPLAIN, but with additional information about how
optimizer estimates match actual execution.
* MySQL now performs injection of casts into queries to
avoid certain data type mismatches; that is, the
optimizer now adds casting operations in the item tree
inside expressions and conditions in which the data type
of the argument and the expected data type do not match.
This makes the query as executed equivalent to one which
is compliant with the SQL standard while maintaining
backwards compatibility with previous releases of MySQL.
Such implicit casts are now performed between temporal
types and numeric types by casting both arguments as
DOUBLE whenever they are compared using any of the
standard numeric comparison operators. They are also now
performed for such comparisons between DATE or TIME
values and DATETIME values, in which case the arguments
are cast as DATETIME.
For example, a query such as SELECT * FROM t1 JOIN t2 ON
t1.int_col = t2.date_col is rewritten and executed as
SELECT * FROM t1 JOIN t2 ON CAST(t1.int_col AS DOUBLE) =
CAST(t2.date_col AS DOUBLE), and SELECT * FROM t1 JOIN t2
ON t1.time_col = t2.date_col is transformed to SELECT *
FROM t1 JOIN t2 ON CAST(t1.time_col AS DATETIME) =
CAST(t2.date_col AS DATETIME) prior to execution.
It is possible to see when casts are injected into a
given query by viewing the output of EXPLAIN ANALYZE,
EXPLAIN FORMAT=JSON, or EXPLAIN FORMAT=TREE. EXPLAIN can
also be used, but in this case it is also necessary to
issue SHOW WARNINGS afterwards.
This change is not expected to cause any difference in
query results or performance.
Packaging Notes
* The component_test_page_track_component.so test plugin
has been moved to -test packages. (Bug #30199634)
* Binary packages that include curl rather than linking to
the system curl library have been upgraded to use curl
7.65.3. (Bug #30015512)
Pluggable Authentication
* To assist in debugging failed connections for accounts
that use an LDAP authentication plugin, the
authentication_ldap_simple_log_status and
authentication_ldap_sasl_log_status system variables now
accept a maximum value of 6 (formerly 5). Setting either
variable to 6 causes debugging messages from the LDAP
library to be written to the error log for the
corresponding plugin. (Bug #29771393)
Spatial Data Support
* Previously, for geometry arguments in a geographic
(ellipsoidal) SRS, ST_Distance() supported only argument
types of Point and Point, or Point and MultiPoint.
ST_Distance() now supports distance calculations for
geographic SRS arguments of all geometry types. For more
information, see Spatial Relation Functions That Use
Object Shapes
(https://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-object-shapes.html).
sys Schema Notes
* The sys.schema_unused_indexes view now filters out unique
indexes. Thanks to Gillian Gunson for the contribution.
(Bug #24798995, Bug #83257)
* The sys.ps_is_consumer_enabled() function now produces an
error rather than returning NULL if the argument is an
unknown non-NULL consumer name. (Bug #24760317)
* Previously, sys schema sources were maintained in a
separate Git repository. sys schema sources now are
included with and maintained within MySQL source
distributions (under scripts/sys_schema). As a
consequence of this change, to simplify maintenance of
sys schema scripts going forward, the acceptable format
of statements in the file named by the init_file system
variable has been expanded. For details, see the
description of that variable in Server System Variables
(https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html).
The sys.version view is deprecated and will be removed in
a future MySQL version. Affected applications should be
adjusted to use an alternative instead. For example, use
the VERSION() function to retrieve the MySQL server
version.
Test Suite Notes
* MySQL tests were updated to use the latest version of
googletest. (Bug #30079649)
X Plugin Notes
* X Protocol did not correctly display large numbers of
warning messages that were issued for the same query.
(Bug #30055869)
* When the NO_BACKSLASH_ESCAPES SQL mode was enabled, X
Plugin incorrectly reported collections as tables. (Bug
#28208285)
Functionality Added or Changed
* When the server is run with --initialize, there is no
reason to load non-early plugins. The server now logs a
warning and ignores any --plugin-load or
--plugin-load-add options given with --initialize. (Bug
#29622406)
* The number of diagnostic messages relating to
INFORMATION_SCHEMA upgrade during server startup has been
reduced. (Bug #29440725, Bug #94559)
* Prior to MySQL 8.0, REVOKE produced an error for attempts
to revoke an unknown privilege. In MySQL 8.0, an account
can possess a privilege that is currently unknown to the
server if it is a dynamic account that was granted while
the component or plugin that registers the privilege was
installed. If that component or plugin is subsequently
uninstalled, the privilege becomes unregistered, although
accounts that possess the privilege still possess it.
Revoking such a privilege cannot be distinguished from
revoking a privilege that actually is invalid, so REVOKE
no longer produces an error for attempts to revoke an
unknown privilege. However, to indicate that the
privilege is currently unknown, REVOKE now produces a
warning. (Bug #29395197)
* The new innodb_idle_flush_pct variable permits placing a
limit on page flushing during idle periods, which can
help extend the life of solid state storage devices. See
Limiting Buffer Flushing During Idle Periods
(https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool-flushing.html#innodb-limit-flushing-rate).
Thanks to Facebook for the contribution. (Bug #27147088,
Bug #88566)
* mysqld invoked with the --help option no longer aborts if
the secure_file_priv argument does not exist. (Bug
#26336130)
* For group communication connections, Group Replication
now supports the TLSv1.3 protocol, which was supported by
MySQL Server from 8.0.16. To use the TLSv1.3 protocol,
MySQL Server must be compiled using OpenSSL 1.1.1 or
higher. For information on configuring encrypted
connections for Group Replication, see Group Replication
Secure Socket Layer (SSL) Support
(https://dev.mysql.com/doc/refman/8.0/en/group-replication-secure-socket-layer-support-ssl.html).
* A new option OFFLINE_MODE is available for the
group_replication_exit_state_action system variable,
which specifies how Group Replication behaves when a
server instance leaves the group unintentionally, for
example after encountering an applier error, or in the
case of a loss of majority, or when another member of the
group expels it due to a suspicion timing out.
When OFFLINE_MODE is specified as the exit action, Group
Replication switches MySQL to offline mode by setting the
system variable offline_mode to ON. When the member is in
offline mode, connected client users are disconnected on
their next request and connections are no longer
accepted, with the exception of client users that have
the CONNECTION_ADMIN or SUPER privilege. Group
Replication also sets the system variable super_read_only
to ON, so clients cannot make any updates, even if they
have connected with the SUPER privilege.
The OFFLINE_MODE exit action prevents updates like the
default READ_ONLY exit action does, but also prevents
stale reads (with the exception of reads by client users
with the stated privileges), and enables proxy tools such
as MySQL Router to recognize that the server is
unavailable and redirect client connections. It also
leaves the instance running so that an administrator can
attempt to resolve the issue without shutting down MySQL,
unlike the existing alternative ABORT_SERVER exit action,
which shuts down the instance.
* By default, MySQL replication (including Group
Replication) does not carry out privilege checks when
transactions that were already accepted by another server
are applied on a replication slave or group member. From
MySQL 8.0.18, you can create a user account with the
appropriate privileges to apply the transactions that are
normally replicated on a channel, and specify this as the
PRIVILEGE_CHECKS_USER account for the replication
applier. MySQL then checks each transaction against the
user account's privileges to verify that you have
authorized the operation for that channel. The account
can also be safely used by an administrator to apply or
reapply transactions from mysqlbinlog output, for example
to recover from a replication error on the channel. The
use of a PRIVILEGE_CHECKS_USER account helps secure a
replication channel against the unauthorized or
accidental use of privileged or unwanted operations.
You grant the REPLICATION_APPLIER privilege to enable a
user account to appear as the PRIVILEGE_CHECKS_USER for a
replication applier thread, and to execute the
internal-use BINLOG statements used by mysqlbinlog. After
setting up the user account, use the GRANT statement to
grant additional privileges to enable the user account to
make the database changes that you expect the applier
thread to carry out, such as updating specific tables
held on the server. These same privileges enable an
administrator to use the account if they need to execute
any of those transactions manually on the replication
channel. If an unexpected operation is attempted for
which you did not grant the appropriate privileges, the
operation is disallowed and the replication applier
thread stops with an error.
* An internal message service has been added to Group
Replication. MySQL modules can use the service to
transmit generic messages with an identifying tag to all
group members, using Group Replication's existing group
communication connections.
* The relay_log_info_file system variable and
--master-info-file option are now deprecated. These were
used to specify the name of the relay log info log and
master info log when --relay-log-info-repository=FILE and
--master-info-repository=FILE were set, but those
settings have been deprecated. The use of files for the
relay log info log and master info log has been
superseded by crash-safe slave tables, which are the
default in MySQL 8.0.
* The --slave-rows-search-algorithms option and the
slave_rows_search_algorithms system variable are now
deprecated. These were used to control how rows were
searched for matches when preparing batches of rows for
row-based logging and replication. The default setting
INDEX_SCAN,HASH_SCAN has been found to be optimal for
performance and works correctly in all scenarios.
* The log_bin_use_v1_row_events system variable is now
deprecated. When set to ON, the variable made mysqld
write the binary log using Version 1 binary log row
events, instead of Version 2 binary log row events which
are the default from MySQL 5.6. (The default is OFF.) The
use of Version 1 binary log row events enabled row-based
replication with slaves running MySQL Server 5.5 and
earlier, which could not use Version 2 binary log row
events.
* The WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() function is now
deprecated, and the WAIT_FOR_EXECUTED_GTID_SET() function
should be used instead. Both functions wait until all of
the specified transactions have been applied, or until
the optional timeout has elapsed. However,
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() applied to a specific
replication channel, and stopped only after the
transactions had been applied on that channel, for which
the applier had to be running. In contrast,
WAIT_FOR_EXECUTED_GTID_SET() stops after the specified
transactions have been applied on the server, regardless
of how they were applied (on any replication channel or
from any user client), and whether or not any replication
channels are running. WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()
could hang indefinitely if an expected transaction
arrived on a different replication channel or from a user
client, for example in a failover or manual recovery
situation, and no timeout was set.
Bugs Fixed
* NDB Cluster: A query handled using a pushed condition
produced incorrect results when it included an ORDER BY
clause. (Bug #29595346)
References: This issue is a regression of: Bug #28672214.
* NDB Cluster: The NDB transporter layer limits the size of
messages to 32768 bytes; send buffers place additional
(and stricter) limitations on message size. Whenever a
message is appended to a send buffer, page checks are
performed to ensure that the message fits in the
available space; if not, a new page is used. The current
issue arose on account of the fact that no check was
performed to make sure that this message could fit in the
empty page; when the size of the message exceeded the
empty page, this resulted in a buffer overwrite and in
the overwriting of the next page in memory. For data
nodes the largest message supported by the send buffer
(thr_send_page) is 32756 bytes; for API and management
nodes, this maximum is 32752 bytes. (Signals sent within
an individual data node are not subject to these
limitations since no send or transporter buffers are used
in this case). Now, when a new page is used, the size of
the message is checked against that which is available in
a new page.
As part of the work done to fix the problem just
described, three new DUMP commands are added to
facilitate related testing and debugging: DUMP 103003
(CmvmiRelayDumpStateOrd) sends a DUMP command using
another node; DUMP 103004 (CmvmiDummySignal) and DUMP
103005 (CmvmiSendDummySignal) can be used to send long
messages. (Bug #29024275)
* NDB Cluster: EXPLAIN FORMAT=TREE did not provide proper
explanations of conditions and joins pushed down to the
NDBCLUSTER storage engine. Issues included the following:
+ Pushed conditions were not shown.
+ The root of a pushed join was not shown.
+ The child of a pushed join did not include any
reference to its parent operation.
* InnoDB: An internal function
(btr_push_update_extern_fields()) used to fetch newly
added externally stored fields and update them during a
pessimistic update or when going back to a previous
version of a record was no longer required. Newly added
externally stored fields are updated by a different
function. Also, the method used to determine the number
of externally stored fields was corrected. (Bug
#30342846)
* InnoDB: An DROP UNDO TABLESPACE operation on an undo
tablespace with a missing data file caused a segmentation
fault. (Bug #30155290)
* InnoDB: An error in the internal
trx_rseg_add_rollback_segments function was corrected.
(Bug #30114226, Bug #96372)
* InnoDB: Problematic assertion code in the
Contention-Aware Transaction Scheduling (CATS) code was
revised. (Bug #30086559)
* InnoDB: Arguments passed to a derived class in calls from
the ib::fatal and ib::fatal_or_error constructors could
be ignored, resulting in invalid error messages.
Additionally, in the case of a fatal error, the
ib::fatal_or_error destructor could cause a server exit
before printing a message. (Bug #30071930)
* InnoDB: It was possible for a corrupted table to be
removed from the table cache before the reference count
for the table reached zero. (Bug #30065947, Bug #96224)
* InnoDB: A code path for the internal
row_update_inplace_for_intrinsic() function did not
include a required mini-transaction (mtr) commit, causing
a debug assertion failure. (Bug #30065518)
* InnoDB: The internal fsp_srv_undo_tablespace_fixup()
function did not take an undo::ddl_mutex lock when called
during startup, which could lead to an assertion failure
under certain circumstances. (Bug #30029433)
* InnoDB: Inspection of rename_tablespace_name() function
showed that if old_shard->get_space_by_id(space_id) did
not find the tablespace ID, it would return without
calling old_shard->mutex_release(). (Bug #30027771)
* InnoDB: A tablespace with "FTS" in its name was
incorrectly determined to be the tablespace of a
full-text index table and not registered with the data
dictionary during upgrade, causing the upgrade operation
to fail. (Bug #29992589)
* InnoDB: The ibuf_merge_or_delete_for_page() function,
responsible for merging and deleting pages in the change
buffer, is no longer called for undo tablespaces and
temporary tablespaces. The change buffer does not contain
entries for those tablespace types. (Bug #29960394, Bug
#95989)
* InnoDB: Some combinations of buffer pool size variables
(--innodb-buffer-pool-instances,
--innodb-buffer-pool-size, and
--innodb-buffer-pool-chunk-size) lead to a chunk size
that is 0, 1, or a value that is not a multiple of the
page size, and so on, causing errors during buffer pool
creation and sizing. (Bug #29951982)
* InnoDB: A server exit while an undo tablespace was being
truncated caused the following error when a clone
operation was rolled forward after restarting the server:
[ERROR] [MY-011825] [InnoDB] [FATAL] Clone File Roll
Forward: Invalid File State: 0. (Bug #29949917)
* InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation
caused a hang condition. (Bug #29942556, Bug #30324703)
* InnoDB: Cloning operations failed with the following
error after an archive thread failure: ERROR 3862
(HY000): Clone Donor Error: 1317 : Query execution was
interrupted. (Bug #29930839)
* InnoDB: A clone related regression caused a minor drop in
performance for index and non-index update operations.
(Bug #29925409)
* InnoDB: InnoDB now ignores hidden directories and files
during the tablespace discovery scan that occurs at
startup. Hidden directories and files include those
beginning with "." and hidden and system directories and
files on Windows that are identified by attributes. (Bug
#29900671, Bug #95071, Bug #30068072)
* InnoDB: To improve deadlock detection, the task of
detecting a deadlock cycle among data locks was moved
from the transaction thread to a dedicated background
thread. (Bug #29882690)
* InnoDB: Updating the mysql.gtid_executed table during
mysqld initialization caused the following warning to be
printed to the error log: [Warning] [MY-010015] [Repl]
Gtid table is not ready to be used. Table
'mysql.gtid_executed' cannot be opened. The update and
associated warning no longer occur. (Bug #29871809)
* InnoDB: The LATEST DETECTED DEADLOCK section in InnoDB
Standard Monitor output (also printed by SHOW ENGINE
INNODB STATUS) was extended to include additional
information about transactions that participate in a
deadlock cycle. (Bug #29871641)
* InnoDB: An incorrect argument was used to compare
serialized dictionary information (SDI) input and output
values when checking the size of the buffer used to store
SDI. (Bug #29871525, Bug #95606)
* InnoDB: An undo tablespace file was overwritten during a
cloning operation when undo tablespaces files with the
same name were copied from different directories on the
donor to the same directory on the recipient. A cloning
operation now reports an error if duplicate undo
tablespace names are encountered. When data is cloned to
the recipient, undo tablespace files are cloned to the
directory defined by the innodb_undo_directory variable.
Because the files are cloned to the same directory,
duplicate undo tablespace file names are not permitted.
(Bug #29837617)
* InnoDB: A cloning operation generated a large number of
redo log files when cloning from a MySQL server instance
with a small redo log file size and a large number of
transactions. The large number of redo log files
sometimes caused startup to hang or assert. Otherwise,
startup was permitted proceed without cleaning up the
excessive number of redo log files. (Bug #29837490)
* InnoDB: During recovery, missing table errors that occur
when applying redo logs to encrypted tables could be
ignored, permitting startup to proceed. Startup should be
halted in this case. (Bug #29820184, Bug #95183)
* InnoDB: The wrong redo log file size was printed to the
server error log at startup. (Bug #29818711)
* InnoDB: A restriction that prevented reuse of lock
objects (lock_t structs) in the lock queue when waiting
record lock requests were present was removed. (Bug
#29814308)
* InnoDB: When converting a long partitioned table name to
a file name, the buffer that holds the file name did not
have enough space, causing an assertion failure. (Bug
#29813582)
* InnoDB: Some transaction lock structure fields
(trx->lock) were not properly mutex protected. (Bug
#29809137)
* InnoDB: An empty undo segment update during recovery
raised an assertion. (Bug #29802703)
* InnoDB: A cloning operation failed when attempting to
drop data on the recipient if the recipient data included
a table with a full-text index. (Bug #29796507)
* InnoDB: After a file-per-table tablespace was discarded,
an error was reported when the old table was renamed and
a new table was created with the same name. The error was
due to stale file path information. (Bug #29793800)
* InnoDB: A test case that attempts to open a file in
read-only mode while the server is in a disk-full state
caused a debug assertion failure. The assertion was
removed to permit the server to retry opening the file,
and to report an error if unsuccessful after a number of
attempts. (Bug #29692250, Bug #95128)
* InnoDB: Foreign-key-related tables constructed during a
RENAME TABLE operation contained the old table name. (Bug
#29686796)
* InnoDB: The server passed a NULL value for a column with
a non-zero data length. (Bug #29654465)
* InnoDB: Importing a partitioned table from a MySQL 8.0.13
instance (or earlier) to a MySQL 8.0.14, 8.0.15, or
8.0.16 instance failed with a "tablespace is missing"
error for source and target instances defined with
lower_case_table_names=1. The tablespace file and the
metadata file used by the import operation could not be
found due to a file name case mismatch. (Bug #29627690,
Bug #94850)
References: This issue is a regression of: Bug #26925260.
* InnoDB: The read set (TABLE::read_set) was not set
properly for handler method calls in
QUICK_SKIP_SCAN_SELECT::get_next(), causing an assertion
failure. (Bug #29602393)
* InnoDB: An exclusive backup lock is now used to block
tablespace truncate operations during master key
rotation. Previously, metadata locks on undo tablespace
names were used to synchronize the operations. (Bug
#29549938)
* InnoDB: An unnecessary next key lock was taken when
performing a SELECT...FOR [SHARE|UPDATE] query with a
WHERE condition that specifies a range, causing one too
many rows to be locked. The most common occurrences of
this issue have been addressed so that only rows and gaps
that intersect the searched range are locked. (Bug
#29508068)
* InnoDB: Adding a virtual column in the first position
together with a normal column raised an assertion
failure. (Bug #29501324)
* InnoDB: The shutdown process did not wait for InnoDB
background threads to exit, which could cause shutdown to
stall, waiting for background threads to remove
transactions from the MySQL transaction list. A check now
occurs to ensure that InnoDB background threads have
exited properly. Also, an intermediate shutdown state was
added to improve shutdown timing for the InnoDB master
thread. (Bug #29417503)
* InnoDB: A memory leak occurred during TempTable storage
engine operation due a failure to deallocate that last
block of allocated memory, which TempTable holds in
thread-local storage until thread exit. (Bug #29300927)
* InnoDB: Delete marked rows were able to acquire an
external read lock before a partial rollback was
completed. The external read lock prevented conversion of
an implicit lock to an explicit lock during the partial
rollback, causing an assertion failure. (Bug #29195848)
* InnoDB: The INFORMATION_SCHEMA.INNODB_COLUMNS table did
not display partitioned table columns after upgrading
from MySQL 5.7 to MySQL 8.0. For partitioned tables
created on the MySQL 8.0 release,
INFORMATION_SCHEMA.INNODB_COLUMNS only displayed columns
for the first table partition. (Bug #28869903, Bug
#93033)
* InnoDB: The internal rtr_page_split_and_insert() function
is called recursively. An inner call to the function
released an object still being used by an outer call to
the same function, causing an assertion failure. (Bug
#28569379)
* InnoDB: Under specific circumstances, setting the
innodb_limit_optimistic_insert_debug variable to 2 raised
a debug assertion when it should have reported an error.
(Bug #28552330, Bug #92187)
* InnoDB: A deadlock was possible when a transaction tries
to upgrade a record lock to a next key lock. (Bug
#23755664, Bug #82127)
* InnoDB: An error reported during a read operation did not
identify the name of the file that was read. (Bug
#21120885, Bug #76020)
Edited 1 time(s). Last edit at 10/14/2019 07:46AM 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.