MySQL Forums
Forum List  »  Announcements

MySQL Community Server 8.0.17 has been released (part 2/3)
Posted by: Balasubramanian Kandasamy
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]


Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Community Server 8.0.17 has been released (part 2/3)
1873
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.