MySQL Community Server 8.0.17 has been released (part 2/3)
Posted by: Balasubramanian Kandasamy
Date: July 22, 2019 03:06AM
Date: July 22, 2019 03:06AM
[This is part 2 of the announcement]
Bugs Fixed
* NDB Cluster: Compile times for NDB Cluster using the
included compile_cluster build script have been improved
by removing options for software components not strictly
necessary for running MySQL Cluster. (Bug #29355872)
* NDB Cluster: Attempting to change an NDB table's column
properties (such as COLUMN_FORMAT) using ALTER TABLE
ALGORITHM=INPLACE was rejected, which is correct
behavior, but which raised a misleading error message.
(Bug #28929906)
* InnoDB: A failure occurred when attempting to kill a
process that was executing a row count. (Bug #29939617)
* InnoDB: Due to a regression introduced in MySQL 8.0.14,
in-place upgrade on a case sensitive file system from
MySQL 5.7 or a MySQL 8.0 release prior to MySQL 8.0.14 to
MySQL 8.0.16 failed for instances with partitioned tables
and lower_case_table_names=1. The failure was caused by a
case mismatch issue related to partitioned table file
names. The fix that introduced the regression was
reverted, which permits upgrades to MySQL 8.0.17 from
MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to
function as normal. However, the regression is still
present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases.
In-place upgrade on a case sensitive file system from
MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 fails
with the following error when starting the server after
upgrading binaries or packages to MySQL 8.0.17 if
partitioned tables are present and
lower_case_table_names=1:
Upgrading from server version version_number with
partitioned tables and lower_case_table_names == 1 on a case sensitive
file
system may cause issues, and is therefore prohibited. To upgrade anywa
y,
restart the new server version with the command line option 'upgrade=F
ORCE'.
When upgrade is completed, please execute 'RENAME TABLE part_table_nam
e
TO new_table_name; RENAME TABLE new_table_name
TO part_table_name;' for each of the partitioned tables.
Please see the documentation for further information.
If you encounter this error when upgrading to MySQL
8.0.17, perform the following workaround:
1. Restart the server with --upgrade=FORCE to force the
upgrade operation to proceed.
2. Identify partitioned table file names with lowercase
suffixes:
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME
LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
3. For each file identified, rename the associated
table using a temporary name, then rename the table
back to its original name.
mysql> RENAME TABLE table_name TO temporary_table_name;
mysql> RENAME TABLE temporary_table_name TO table_name;
4. Verify that there are no partitioned table file
names with lowercase suffixes (an empty result set
should be returned).
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME
LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
Empty set (0.00 sec)
5. Run ANALYZE TABLE on each renamed table to update
the optimizer statistics in the
mysql.innodb_index_stats and
mysql.innodb_table_stats tables.
Because of the regression still present in the MySQL
8.0.14, 8.0.15, and 8.0.16 releases, importing
partitioned tables from MySQL 8.0.14, 8.0.15, or 8.0.16
to MySQL 8.0.17 is not supported on case sensitive file
systems where lower_case_table_names=1. Attempting to do
so results in a "Tablespace is missing for table" error.
(Bug #29823032, Bug #29917793, Bug #95834)
References: This issue is a regression of: Bug #26925260.
* InnoDB: lock_sys mutex contention caused by lock-wait
functions (lock_wait_suspend_thread() and
lock_wait_table_release_slot()) was reduced. (Bug
#29814339)
* InnoDB: The fseg_n_reserved_pages_low() function, which
determines the number of pages reserved by a segment, did
not validate results read from the segment inode. (Bug
#29761998)
* InnoDB: Creation of the transaction rollback list
(hit_list) was decoupled from lock acquisition calls
(lock_rec_lock calls) to permit the use of different
latching schemes. (Bug #29753800)
* InnoDB: Disabling Performance Schema consumers caused an
ALTER TABLESPACE ... ENCRYPTION operation to assert. (Bug
#29646974, Bug #95005)
* InnoDB: Error messages were revised to remove references
to .frm files, which are not used in MySQL 8.0. (Bug
#29639655)
* InnoDB: It was possible for a background thread to check
the encryption status of an undo tablespace before the
undo tablespace was fully initialized and the encryption
flag set. (Bug #29600309)
* InnoDB: A table name parsing function call returned false
when parsing serialized dictionary information (SDI)
tables names, which are not formatted to include a
database name. The buffer that holds the database name
remained uninitialized, causing Valgrind errors. (Bug
#29550527)
* InnoDB: The space reserved in the mini-transaction (mtr)
log buffer for dynamic metadata logging was insufficient.
(Bug #29524260)
* InnoDB: Inaccuracies in the Variance-Aware Transaction
Scheduling (VATS) implementation raised a signed integer
overflow error in an UBSan build of MySQL. (Bug
#29508517, Bug #91959)
* InnoDB: Insufficient memory barriers in the rw-lock
implementation caused deadlocks on ARM.
Thanks to Yibo Cai from Arm Technology for the
contribution. (Bug #29508001, Bug #94699)
* InnoDB: The INFORMATION_SCHEMA.INNODB_TABLESPACES
ENCRYPTION column was not updated after enabling undo
tablespace encryption. (Bug #29492911, Bug #94665)
* InnoDB: A relocated table could not be accessed due to
incorrect parsing of a schema or table name that included
a forward slash character (/), which the server
incorrectly interpreted as a directory separator. (Bug
#29492113)
* InnoDB: Various fixes and revisions were applied to the
InnoDB memcached source code. (Bug #29485891)
* InnoDB: To enable global access, the value of
innodb_directories variable is now stored internally as a
global variable instead of a static variable. (Bug
#29471990)
* InnoDB: In debug builds, the thd_innodb_tmpdir() function
did not accept a NULL argument. (Bug #29471846)
* InnoDB: A subtraction operation in the file space
allocation code incorrectly stored the result as an
unsigned variable, which raised an assertion failure.
(Bug #29466680)
* InnoDB: After moving or deleting default undo tablespaces
and restarting the server with a new
innodb_undo_directory value, MySQL recreated the undo
tablespaces in the new location but failed to update the
undo directory path in the data dictionary. (Bug
#29461900)
* InnoDB: A previously freed LOB page was accessed while
rolling back a transaction during recovery. (Bug
#29440408)
* InnoDB: A request was issued during recovery to read
pages into the buffer pool when there were no pages to be
read. A check was added to avoid the unnecessary read
request. (Bug #29440208)
* InnoDB: A regression introduced in MySQL 8.0.14 caused a
"Invalid (old?) table or database name" error when
creating a partitioned table on a MySQL instance with
lower_case_table_names=1. The change that caused the
regression has been reverted. (Bug #29426720, Bug #94519)
References: This issue is a regression of: Bug #26925260.
* InnoDB: A FULLTEXT index table created in MySQL 5.6 in a
database with a hyphen in its name caused a startup
failure after upgrading from MySQL 5.7 to MySQL 8.0.
Tablespace file paths for FULLTEXT auxiliary tables were
not found in the data dictionary, and the hyphen in the
database name was not handled correctly in subsequently
generated file paths. (Bug #29411899, Bug #94431)
* InnoDB: There was potential for data loss to occur if the
redo log was not logically empty and comprised a single
block, and the server exited during recovery after an
insert buffer merge generated new redo records but before
the new records could be flushed to disk. (Bug #29411832,
Bug #94448)
* InnoDB: InnoDB returned an unknown generic error when
attempting to create a tablespace for which the path and
file name exceeded the MAX_PATH limit on Windows. InnoDB
now returns a more meaningful error. (Bug #29341634)
* InnoDB: An undo tablespace file was not found after being
moved to a different directory. (Bug #29328158)
* InnoDB: The server failed to start with an
innodb_buffer_pool_size=default setting. The default
value was not checked for compatibility with dependent
system variable settings. (Bug #29267814, Bug #94065)
* InnoDB: The CREATE TABLESPACE ... ADD DATAFILE clause no
longer permits circular directory references. For
example, the circular directory reference (/../) in the
following statement is not permitted:
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd';
An exception to this restriction exists on Linux, where a
circular directory reference is permitted if the
preceding directory is a symbolic link. For example, the
data file path in the example above is permitted if
any_directory is a symbolic link. (It is still permitted
for data file paths to begin with '../'.)
To avoid upgrade issues, remove any circular directory
references from tablespace data file paths before
upgrading to MySQL 8.0.17 or higher. To inspect
tablespace paths, query the
INFORMATION_SCHEMA.INNODB_DATAFILES table. (Bug
#29157265)
* InnoDB: Manually changing the system time while the MySQL
server was running caused page cleaner thread delays.
(Bug #29138644, Bug #93708)
* InnoDB: UPDATE statements did not always disable
semi-consistent reads properly when encountering errors,
which could lead to assertion errors in debug mode. (Bug
#29047894)
* InnoDB: When purging a deleted row, the logic that
governs lock inheritance did not correctly determine the
type of lock that should be inherited to satisfy
constraint checks by active transactions. (Bug #29004362)
* InnoDB: An unnecessary read lock was taken on implicitly
opened data dictionary tables when executing a prepared
statement in LOCK TABLES mode. (Bug #28875646)
* InnoDB: During log application, after an OPTIMIZE TABLE
operation, InnoDB did not populate virtual columns before
checking for virtual column index updates. (Bug
#28834208)
* InnoDB: An operation that copied data from the clustered
index was performed incorrectly, causing spatial indexes
to use spatial rows with stale pointers to the clustered
index. (Bug #28758961)
* InnoDB: An INSERT operation involving a generated virtual
BLOB column resulted a secondary index being updated with
an incorrect value. (Bug #28652826)
* InnoDB: Configuring innodb_data_file_path and
innodb_temp_data_file_path using SET PERSIST_ONLY =
default incorrectly set the variable values to NULL. (Bug
#28590014)
* InnoDB: A CREATE TABLE ... REPLACE SELECT operation
raised a lock_rec_get_rec_not_gap(lock) assertion
failure. The operation set a flag on the transaction
object indicating that a REPLACE operation was requested,
but did not clear the flag before updating dependent
views, causing a subsequent INSERT operation to be
interpreted as a REPLACE operation, leading to the wrong
row locks being taken. (Bug #28523025, Bug #92068)
* InnoDB: With super_read_only enabled, an attempted RENAME
TABLE operation on a temporary table raised an assertion
instead of returning an error. (Bug #28490368, Bug
#91975)
* InnoDB: Valgrind errors were reported due to
uninitialized bytes read during a virtual index prefix
search. (Bug #28184025)
* InnoDB: InnoDB initialization failed when attempting to
create an system tablespace greater than 2GB in size.
(Bug #27538464)
* InnoDB: A full-text cache lock taken when data is
synchronized was not released if the full-text cache size
exceeded the full-text cache size limit. (Bug #25289359)
* InnoDB: The INNODB_METRICS metadata_table_reference_count
counter reported a negative value. (Bug #20584149, Bug
#75966)
* InnoDB: Client sessions using different
auto_increment_increment values while performing
concurrent insert operations could cause a duplicate key
error. (Bug #15851528, Bug #67526)
References: Reverted patches: Bug #14049391, Bug #65225.
* Partitioning: For partitioned tables, an ALTER TABLE
statement could cause incorrect query results under these
conditions:
+ The statement swapped columns by renaming them,
either directly with RENAME COLUMN or by replacement
with DROP COLUMN/ADD COLUMN.
+ A swapped column was used in a partitioning
expression.
+ The alteration was performed as an in-place
operation that did not redistribute rows between
partitions.
Such column renames are now prohibited unless the same
ALTER TABLE statement satisfies one of these conditions:
+ The statement makes the table nonpartitioned.
+ The statement redefines the table partitioning or
partitioning expression (which causes a table
rebuild that redistributes rows). This enables
supporting existing scenarios in which partitioning
expressions are updated to follow column renaming.
+ Partitioning is specified using PARTITION BY KEY()
with an empty column list. This partitions using the
primary key, which tracks column renaming.
(Bug #29541665, Bug #94792)
* Partitioning: ALTER TABLE ... EXCHANGE PARTITION failed
with the error Non matching attribute 'ROW_FORMAT'
between partition and table when the partitioned table
had partitions using different row formats, even when the
partition to be exchanged used the same row format as the
non-partitioned table. (Bug #28687608)
* Replication: When message fragmentation is in use for
large Group Replication messages (which is available, and
the default, from MySQL 8.0.16), if a fragmented message
sent by the group member with the highest node identifier
in XCom was partially delivered, and one or more members
then left the group prior to the delivery of the
remaining message fragments, reassembly of the message
caused Group Replication to stop working. The loss of
members meant that the node identifier of the original
sender was no longer valid in the new view of the group.
To correct this issue, reassembly of fragmented messages
now uses the delivery information from the last fragment
that was delivered, which reflects the new situation
after the view change, rather than from the first
fragment that was delivered, which reflects the old
situation before the view change. (Bug #29716639)
* Replication: The error message that is issued for a
discrepancy between the number of group members and the
auto-increment interval incorrectly referred to the
group_replication_auto_increment_increment system
variable, instead of the auto_increment_increment system
variable. The value of auto_increment_increment is
changed to the value specified by
group_replication_auto_increment_increment when Group
Replication starts, but only if auto_increment_increment
and auto_increment_offset have their default values, and
from MySQL 8.0, only in multi-primary mode. The value of
auto_increment_increment was always the value that was
checked for the error message, and it has now been
corrected to give the accurate system variable name. (Bug
#29542425)
* Replication: Group Replication cannot be started
following a MySQL Server upgrade that uses the MINIMAL
option (--upgrade=MINIMAL), which does not upgrade system
tables on which the replication internals depend.
Previously, in this situation, the server was waiting
indefinitely for Group Replication to start. The
situation is now handled correctly by unblocking the
waiting thread and issuing the expected error
ER_GRP_RPL_START_GRP_RPL_FAILED. (Bug #29423358)
* Replication: In Group Replication's Group Communication
System (GCS), a change to the processing of suspicions by
a member that is leaving the group, which reduced the
execution time for some test cases, caused an issue in
the event that recovery failed, because it led to a
circular dependency between the recovery failure and the
view change notification. Now, if an error makes recovery
impossible, GCS takes the handling actions in an
appropriate sequence. The member leaves the group, the
view change is applied, and then the recovery thread is
terminated. (Bug #29417365, Bug #29628909)
* Replication: When events generated by one MySQL server
instance were written to the binary log of another
instance, the second server implicitly assumed that the
first server supported the same number of binary log
event types as itself. Where this was not the case, the
event header was handled incorrectly. The issue has now
been fixed. Thanks to Facebook for the contribution. (Bug
#29417234)
* Replication: In Group Replication, joining members could
wrongly identify themselves as incompatible with an
existing replication group even if there were members at
the same version already in the group, because they
checked against all other members, including the member
at the highest version. Joining members also included
their own version in the compatibility check. Now,
joining members only compare themselves with the existing
group member at the lowest version, and do not count
their own version. (Bug #29390946)
* Replication: If a LOCK INSTANCE FOR BACKUP statement was
used to acquire an instance-level backup lock, then a
STOP SLAVE statement was issued, a deadlock could be
created with the SQL thread waiting on the backup lock
and the STOP SLAVE statement waiting on the SQL thread to
complete its current action. To prevent this situation,
the STOP SLAVE process now tries to acquire the backup
lock before proceeding, and returns an error if the lock
cannot be acquired. (Bug #29386503, Bug #93649)
* Replication: From MySQL 8.0.13, if any replication
channel has open temporary tables, the binary logging
format cannot be changed using SET @@global.binlog_format
or SET @@persist.binlog_format. Previously, if this
operation was attempted after the new restriction was
implemented, the wrong error message was returned to the
client (referencing a running replication channel applier
as the issue, rather than an open temporary table). The
appropriate error message is now returned. (Bug
#29370024, Bug #94340)
* Replication: Binary log checksums were handled
incorrectly when de-serializing a format description
event. (Bug #29355110)
* Replication: With row-based replication in use, when the
replication applier thread unpacked a row change event,
index values for any functional indexes were calculated
for both the "before" image and the "after" image. In the
case of the "before" image, the values were not
necessary. This calculation has therefore been removed
for the before image in order to optimize row unpacking.
(Bug #29304076)
* Replication: When a MEMORY table is implicitly deleted on
a master following a server restart, the master writes a
DELETE statement to the binary log so that slaves also
empty the table. This generated event now includes a
comment in the binary log so that the reason for the
DELETE statement is easy to identify. Thanks to Daniël
van Eeden for the contribution. (Bug #29157796, Bug
#93771)
* Replication: If an invalid starting offset was provided
in a SHOW BINLOG EVENTS FROM statement, the invalid
offset was returned in place of the correct starting
position for the first returned event. (Bug #29039732,
Bug #93544)
* Replication: The Group Replication UDFs for configuring
an online group sometimes did not return an error if an
issue arose during main execution. The UDFs also now
check whether the Group Replication plugin is stopping
before they start to initialize. (Bug #28978767)
* Replication: Replication could stop with a "record not
found" error when the value INDEX_SCAN,HASH_SCAN (the
default in MySQL 8.0) was set for the
slave_rows_search_algorithms system variable, and an
update event contained two updates to the same row in a
table that did not have a unique key, meaning that the
hash scan was used. In this situation, the second update
was missed by the hash scan due to the row change. Now,
after updating a row, the hash scan operation searches
for the updated row in the hash map, and applies any
further update.
When the value TABLE_SCAN,HASH_SCAN is set for the
slave_rows_search_algorithms system variable, so that the
search cannot use an index, the "record not found" error
can occur in the above situation whether or not the table
has a unique key. Also, with this setting, when a hash
scan is used on a table that has a unique key, in the
case of an update event containing two row updates that
are order-dependent, the updates might be applied out of
order, causing replication to stop with a duplicate key
error. To avoid these issues, the documentation has been
updated to state that the value TABLE_SCAN,HASH_SCAN
should not be used. (Bug #28846386)
* Replication: When binary logging is enabled on a
replication slave, the combination of the
--replicate-same-server-id and --log-slave-updates
options on the slave can cause infinite loops in
replication if the server is part of a circular
replication topology. (In MySQL 8.0, binary logging is
enabled by default, and slave update logging is the
default when binary logging is enabled.) However, the use
of global transaction identifiers (GTIDs) prevents this
situation by skipping the execution of transactions that
have already been applied. The restriction on this
combination of options has therefore now been removed
when gtid_mode=ON is set. With any other GTID mode, the
server still does not start with this combination of
options. As a safeguard against creating the problem
situation after the server has started, you now cannot
change the GTID mode to anything other than ON on a
running server that has this combination of options set.
Thanks to Facebook for the contribution. (Bug #28782370,
Bug #92754)
* Replication: The group communication engine for Group
Replication (XCom, a Paxos variant) did not handle out of
memory errors in an appropriate way. If memory could not
be allocated to make a copy of the payload for a message,
an error was logged but the message was still sent, with
a null payload. The Group Communication System (GCS) on
the receiving member discarded the message as empty, and
the XCom instance on the receiving member accepted this
action and did not retry, resulting in the message
effectively being skipped. This caused the GTID set on
the receiving member to diverge from the group, leading
to replication errors. XCom now terminates gracefully if
it experiences an out of memory error, so that this
situation cannot occur. (Bug #28702320)
* Replication: In query log events in the binary log, the
thread ID used for the execution of DROP TABLE and DELETE
statements was identified incorrectly or not at all. On a
multi-threaded replication slave, where temporary tables
were involved (which require the correct thread ID as
they are session specific), this omission resulted in
errors when using mysqlbinlog to replay the binary log
for point-in-time recovery. The thread ID is now set
correctly. (Bug #28642318, Bug #92398)
* Replication: When a trigger invoked an INSERT or UPDATE
statement that set a column to its default value, and the
DEFAULT expression of that column was non-deterministic,
the expected warning was not raised when the trigger
fired under statement-based replication. In addition, if
the binary logging format was MIXED, the
non-deterministic statements were logged in the format
used for STATEMENT rather than that used for ROW.
The statement that causes the trigger to fire checks at
resolution time whether any of the triggered statements
are non-deterministic. At this time, the triggered
statements have been parsed, but not resolved, so the
only check that can be performed is whether the triggered
statements directly reference any non-deterministic
operators. When the non-deterministic operator is used by
a DEFAULT expression, the non-determinism is not visible
until the triggered statement has been resolved, which
happens when the trigger fires.
This is fixed by adding an extra check when determining
the logging format, where a statement is flagged as
unsafe if any of its substatements can write to a table
that has a column with a non-deterministic DEFAULT
expression. Since it is not yet known at this point
whether the DEFAULT expression will be used by the
substatement, this check flags the statement as unsafe
even if the substatement provides an explicit value for
the column with a non-deterministic DEFAULT expression.
(Bug #28297486)
* Replication: When a slave server logs master status and
connection information to a table
(master_info_repository=TABLE), which is the default in
MySQL 8.0, the mysql.slave_master_info table was not
being updated on shutdown if the server was in super read
only mode (super_read_only=ON). No error was written to
the error log at this time, but replication failed after
server startup because the master log file and master log
position information was out of date. The thread that
updates the master info log at shutdown is now excluded
from read-only checks like other replication threads are,
so it can update the table even if the server is in super
read only mode. Error handling for a slave that is
shutting down has also been improved so that any failure
to write to the slave status logs results in an error in
the error log. (Bug #27675107, Bug #89987)
* Replication: If a replication slave tried to connect to
the master using an incorrect user name, host, or port,
the original error message specifying the reason for the
connection failure was overwritten with a generic
message. The issue has now been corrected in the output
from the SHOW SLAVE STATUS statement and in the
Performance Schema table replication_connection_status.
(Bug #26580064)
* macOS: For macOS installations performed using DMG
packages, launchd operation was problematic:
+ Previously, SHUTDOWN caused a restart if MySQL was
configured to start at boot time via the preference
pane. This also affected the mysqladmin shutdown
command. Server shutdown initiated in these ways now
works correctly.
+ Previously, RESTART did not work. It now works
correctly.
+ Previously, unexpected server exits did not cause
automatic restart if the server was not configured
to start at boot time. Exits with a nonzero exit
status now cause a restart regardless of boot-time
startup configuration.
(Bug #29789857)
* JSON: MAX() and MIN() used on expressions returning JSON
data sometimes compared these values as strings rather
than JSON values, which caused unexpected results; this
was particularly evident when the JSON values were
numbers.
This was due to the fact that GROUP BY when using
temporary tables with indexes did not compare JSON values
correctly. (Bug #28947381)
* JSON: JSON_TABLE() returned the error Unknown database ''
when executed from a stored function.
The root cause of this issue was that, when merging
tables from a select that used JSON_TABLE(), MySQL
checked only for derived tables. This caused the result
table returned by JSON_TABLE() to be noted as a regular
table, so that when attempting to execute the query, the
server failed to open it. Now MySQL checks whether the
table to be added is not an internal table, that is, not
a derived table, a JSON_TABLE() result table, or a
reference to a recursive common table expression. (Bug
#92976, Bug #28851656)
* Some foreign key error messages could differ depending on
whether the user had the GRANT OPTION privilege. (Bug
#29868844)
* During upgrade operations, upgrades of the help tables
failed if autocommit was disabled. (Bug #29865428, Bug
#95620)
* Fetching dynamically allocated dictionary objects into a
vector during upgrade while operating with a small
table_open_cache size caused data dictionary tables to be
reopened, triggering a garbage collection mechanism that
incorrectly freed collected objects. Subsequent attempts
to access the freed objects caused a segmentation fault.
(Bug #29823053)
* For upgrades from MySQL 5.7 to 8.0, the upgrade process
did not close the innodb_*_stats_backup57.ibd files in
the mysql system schema before removing them, resulting
in errors for subsequent file system operations. (Bug
#29791350)
* mysqld --initialize would fail if the file system was
mounted at the data directory mount point and a
lost+found file or directory was present. The lost+found
file or directory is now ignored during data directory
initialization. (Bug #29780434)
* MySQL upgrades did not assign the AUDIT_ADMIN privilege
to accounts that had the SUPER privilege. (Bug #29770732)
* The REGEXP_REPLACE() function did not handle empty
strings correctly in all cases. (Bug #29763554)
* An overly strict assertion could be raised during sorting
of stored program local objects. (Bug #29759547, Bug
#95062)
* The group_replication_get_communication_protocol() UDF,
which is used to query the group's communication protocol
version, failed if any group members were in RECOVERING
state, which was an unnecessary restriction. The UDF can
now be used provided that the member where it runs is in
ONLINE state, and is in contact with a majority of the
group. (Bug #29754967)
* For some arguments to REPEAT(), maximum length
calculations were not always handled correctly. (Bug
#29739778)
* UPDATE statements for tables with CHECK constraints could
fail to enforce the constraints. (Bug #29706621, Bug
#95189)
* For installation from RPM or Debian packages, if the
mysql_upgrade_info file in the data directory is found to
exist but is owned by root, it is now changed to the same
owner as the data directory. The correct SELinux file
context is also set. (Bug #29704041)
* Installing from RPM packages could result in an error log
with incorrect permissions. (Bug #29702462)
* A mysql_upgrade_info file created by the mysql_upgrade
program during a previous upgrade could only be modified
the operating system user that executed the mysql_upgrade
program, causing an upgrade error. A warning is now
issued instead of an error, which permits the upgrade
operation to proceed. The mysql_upgrade_info file is
deprecated and will be removed in a future MySQL version.
(Bug #29702060, Bug #95165)
* A replication group member that was unable to contact a
majority of the group before the
group_replication_unreachable_majority_timeout setting
was reached, and then exhausted the number of auto-rejoin
attempts specified by the
group_replication_autorejoin_tries system variable
without successfully rejoining, was sometimes unable to
carry out the action specified by the
group_replication_exit_state_action system variable. The
member tries to carry out the action using the current
session, which sometimes failed. The member now ensures
that the session is initialized before using it to
connect to the server to carry out the exit state action.
(Bug #29698754)
* When performing a upgrade, server-side SQL statements
that update data dictionary tables used a non-default
collation, causing an upgrade failure. (Bug #29697670,
Bug #95144)
* Starting the server with --skip-grant-tables and invoking
ROLES_GRAPHML() could lead to a server exit. (Bug
#29681975)
* SELECT DISTINCT when using fixed-length keys did not
deduplicate records properly in all cases. (Bug
#29628699)
* Client programs that used asynchronous C API functions
could access freed memory after occurrence of a fatal
error such as connection failure or receipt of a
too-large packet. (Bug #29596244)
* For failed data directory initialization, the server
could produce a message indicating that the directory
could be removed, even if the server itself did not
create it. The message now indicates that only files in
the directory created by the server can be removed. (Bug
#29594082, Bug #94880)
* In MySQL 8.0, the keyring_encypted_file plugin could not
read a file created by a MySQL 5.7 keyring_encypted_file
plugin. (Bug #29588345)
* In builds with Undefined Behavior Sanitizer enabled,
runtime errors occurred in my_strtoll10_mb2() and
val_decimal(). (Bug #29585648, Bug #29594951)
* Some diagnostics produced by the server while checking
grant table structure at startup were written as errors
rather than warnings. (Bug #29558993)
* The comp_err utility could read uninitialized data. (Bug
#29550442)
* Enabling audit log encryption could cause a server exit.
(Bug #29549327)
* RPM package obsoletes were updated to enable successful
upgrades from MariaDB to MySQL on EL8. (Bug #29549127,
Bug #29623146, Bug #29623201, Bug #29659212)
* In a join of the form LEFT JOIN t ON column WHERE t.x=0
IS NOT TRUE, MySQL evaluated IS NOT TRUE as FALSE for a
NULL argument in a null-complemented row, and rejected
it. This caused an invalid conversion of the left join to
an inner join, so that there were missing rows in the
result. The same issue affected joins of the same form
but having IS NOT FALSE in the WHERE condition. (Bug
#29540230)
* If the read_only system variable was enabled, its value
improperly was applied against updates to the character
set and collation data dictionary tables. (Bug #29533590,
Bug #94769)
[To be continued]
Subject
Views
Written By
Posted
MySQL Community Server 8.0.17 has been released (part 2/3)
3087
July 22, 2019 03: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.