MySQL Forums
Forum List  »  Announcements

MySQL Community Server 8.0.13 has been released (part 2/2)
Posted by: Bjørn Munch
Date: October 22, 2018 08:42AM

[This is part 2 of the announcement]


Bugs Fixed


     * Important Note: The libevent library included with the
       MySQL Server was upgraded to version 2.1.8. (Bug
       #28207237)

     * InnoDB; Partitioning: Removed old InnoDB handler and
       partitioning code that referenced .frm files, and thus no
       longer had any purpose. (Bug #27995316)

     * InnoDB: An assertion was raised during a DROP TABLE
       operation. A thread that was accessing the table through
       the memcached API released metadata locks before
       releasing the table. (Bug #28531148)

     * InnoDB: The being_modified bit in a LOB reference was set
       but the bit modification was not logged, causing an
       assertion failure. (Bug #28443837)

     * InnoDB: Window functions returned incorrect results when
       the optimizer used the InnoDB storage engine for internal
       temporary tables. (Bug #28430650)

     * InnoDB: Adjusting the server time to an earlier time
       caused periodic redo flushes to be missed. (Bug
       #28430358, Bug #90670)

     * InnoDB: An ALTER TABLE operation that added a primary key
       produced a segmentation fault. (Bug #28395278)
       References: This issue is a regression of: Bug #27753193.

     * InnoDB: A conditional check was removed by removing the
       ReadView::complete() function and splitting its work
       among other functions. This change helps optimize
       performance on ARM 64-bit. (Bug #28385211, Bug #91759)

     * InnoDB: Leftover thread_mutex code was removed from
       InnoDB source code files. (Bug #28363673, Bug #91678)

     * InnoDB: Type changes were implemented to eliminate
       warnings that occurred when compiling InnoDB with
       Microsoft Visual Studio 2017. (Bug #28338720)

     * InnoDB: An invalid assertion was raised when a B-tree
       flag used to mark shared index locks was used to mark a
       shared-exclusive index lock. (Bug #28317172)

     * InnoDB: The sharp checkpoint mechanism no longer forces
       preflushing of dirty pages when requesting a checkpoint
       for the currently available LSN.
       The log checkpointer thread now takes the concurrency
       margin (the per thread margin for free space in the log)
       into account when determining if the next checkpoint
       write is required and whether to wake up page cleaners to
       force a sync-flush of dirty pages. Page cleaner threads
       take the concurrency margin into account when determining
       whether to flush dirty pages and how many pages to flush.
       (Bug #28297462)

     * InnoDB: A misplaced debug crash point caused a
       transaction timeout resulting in test failures. (Bug
       #28295814)

     * InnoDB: InnoDB error message format was modified to
       remove duplicate text. (Bug #28289789)

     * InnoDB: Unnecessary cycles of freeing and allocating
       memory caused JSON performance degradation on Windows.
       (Bug #28278737)

     * InnoDB: To avoid checking hardware support each time a
       hardware-optimized checksum is computed, asserts were
       converted to debug-only asserts. (Bug #28267334, Bug
       #91485)

     * InnoDB: A patch that combined Variance-Aware Transaction
       Scheduling (VATS) with functionality that releases read
       locks caused gap locks to be removed without granting
       locks to waiting transactions, resulting in transaction
       timeouts. (Bug #28261530)
       References: This issue is a regression of: Bug #28261530.

     * InnoDB: The log_checkpointer thread failed to write new
       checkpoints in a timely manner when the amount of redo
       was small. (Bug #28220222)

     * InnoDB: The server exited during an in-place upgrade from
       MySQL 5.7 to MySQL 8.0 due to an attempted eviction of a
       foreign-key-related table from the cache. At the end of
       the upgrade process, tables with FULLTEXT indexes were
       marked as ready for eviction without checking for foreign
       key relationships. (Bug #28212734, Bug #91325)

     * InnoDB: The format of the following Performance Schema
       and INFORMATION_SCHEMA table columns was modified:

          + data_locks.ENGINE_LOCK_ID

          + data_lock_waits.REQUESTING_ENGINE_LOCK_ID

          + data_lock_waits.BLOCKING_ENGINE_LOCK_ID

          + INNODB_TRX.TRX_REQUESTED_LOCK_ID
       The previous format was trx_id:table_id for table locks
       and trx_id:space_id:page_no:heap_no for record locks. The
       new format is trx_immutable_id:table_id:lock_immutable_id
       for table locks and
       trx_immutable_id:space_id:page_no:heap_no:lock_immutable_
       id for record locks.
       lock_immutable_id and trx_immutable_id are 64-bit values
       that do not change during the lifetime of a lock or
       transaction, respectively, and are unique among other
       instance object IDs. (Bug #28176910)

     * InnoDB: The list of permitted lock mode descriptors used
       by the LOCK_MODE column of the Performance Schema
       data_locks table was expanded to include REC_NOT_GAP,
       INSERT_INTENTION, PREDICATE, and PRDT_PAGE. REC_NOT_GAP
       indicates a record-only lock. INSERT_INTENTION indicates
       an insert intention lock. PREDICATE and PRDT_PAGE
       descriptors indicate a spatial index lock. (Bug
       #28176805)

     * InnoDB: Table names were not compared in lowercase on
       macOS with a setting of lower_case_table_names=2, which
       caused instability after restarting the server. (Bug
       #28170699, Bug #91204)

     * InnoDB: Macros used to define constant values in InnoDB
       source code were changed to constant expressions. (Bug
       #28152926)

     * InnoDB: A flag that prevents transactions from being
       rolled back during commit is now set earlier to prevent
       scenarios in which a high priority transaction could
       abort a transaction that is in the process of being
       committed. (Bug #28140462)

     * InnoDB: A query that scanned the primary key of a table
       did not return the expected result. (Bug #28104394, Bug
       #91032)

     * InnoDB: Unnecessary header file inclusions were removed
       from InnoDB source code files. (Bug #28086759)

     * InnoDB: An apparent hang due to the log writer running
       out of free space in the redo log caused the server to
       exit. (Bug #28072385, Bug #90993)

     * InnoDB: A query interruption during a lock wait caused an
       error. (Bug #28068293)

     * InnoDB: After upgrading from MySQL 5.7 to MySQL 8.0,
       invalid warnings indicated that undo tablespace IDs were
       not in the undo tablespace range. The warnings occurred
       if the MySQL 5.7 installation was configured to use
       separate undo tablespaces. (Bug #28060337)

     * InnoDB: Error messaging was improved for startup failures
       on an incomplete cloned data directory. (Bug #28032131)

     * InnoDB: A segmentation fault occurred during an XA COMMIT
       operation. (Bug #27995891)

     * InnoDB: Unused code was removed from the TempTable
       storage engine source code. (Bug #27978968)

     * InnoDB: An index record was not found when updating a
       secondary index defined on a generated column. (Bug
       #27968952)

     * InnoDB: A spurious negation operator in an IF condition
       caused the Variance-Aware Transaction Scheduling (VATS)
       algorithm to be used for table locks. (Bug #27944920)
       References: This issue is a regression of: Bug #27572937.

     * InnoDB: The update log applied as part of an online ALTER
       TABLE operation did not take into account the computed
       value of the generated column in the old row while
       updating the secondary index. (Bug #27921932)

     * InnoDB: Buffer pool memory allocation was not fully
       accounted for in Performance Schema
       memory/innodb/buf_buf_pool statistics. (Bug #27917595,
       Bug #90561)

     * InnoDB: An unsupported DDL operation involving a foreign
       key constraint raised an assertion. (Bug #27912873)

     * InnoDB: A lock-related debug assertion failure was raised
       when more than one lock matched a search condition, which
       could lead to releasing the wrong lock. (Bug #27898384)

     * InnoDB: A function that removes aborted indexes during
       the prepare phase of an online ALTER TABLE operation did
       not record its changes. (Bug #27879325)

     * InnoDB: A general tablespace created in MySQL 5.7 with no
       assigned table caused a failure when upgrading to MySQL
       8.0. (Bug #27877485)

     * InnoDB: Concurrent undo tablespace truncation and master
       key rotation operations raised an assertion. (Bug
       #27872369)

     * InnoDB: A boolean marker identifying whether a
       transaction holds a mutex was not placed in the correct
       location. (Bug #27870035)

     * InnoDB: An attempted foreign key check on a discarded
       table caused a segmentation fault. (Bug #27804668)

     * InnoDB: B-tree bulk load operations could leave a page in
       a partially initialized state. (Bug #27802098)

     * InnoDB: Starting the server inside a Docker container on
       a NUMA enabled operating system raised an "mbind:
       Operation not permitted" error. (Bug #27792853)

     * InnoDB: A partitioned table TABLE_ID value stored in a
       storage-engine-private data field in the data dictionary
       was not adjusted properly after an ALTER TABLE ...
       PARTITION operation. (Bug #27784462)

     * InnoDB: The server halted with a "log writer overwriting
       data after checkpoint - waited too long" error. (Bug
       #27779266)

     * InnoDB: With innodb_flush_log_at_trx_commit=2, the
       log_flusher thread could wait for an event with a timeout
       period equal to the innodb_flush_log_at_timeout setting,
       causing an initialization delay. (Bug #27762596)

     * InnoDB: An assertion was raised during an OPTIMIZE TABLE
       operation. (Bug #27753193)

     * InnoDB: Transaction rollback due to a deadlock caused an
       assertion failure in debug builds. Initiation of an
       attachable transaction for accessing the data dictionary
       was not expected during transaction rollback. (Bug
       #27729974)

     * InnoDB: With innodb_flush_log_at_trx_commit=0 and binary
       logging enabled, redo logs were not flushed as expected
       during the commit phase of DDL operations. (Bug
       #27691035)

     * InnoDB: With REDUNDANT or COMPRESSED row format and READ
       COMMITTED isolation level, only the LOB value prefix and
       possibly the external part of an old LOB value were
       returned, which could cause a JSON document to be viewed
       as corrupted. If there was no LOB value prefix, an old
       LOB value with new values for other fields could be
       returned, causing data inconsistency. (Bug #27624990)

     * InnoDB: A debug option that permits pausing periodic
       checkpoints became obsolete after periodic checkpoint
       ownership was moved from the master thread to a log
       checkpointer thread. The debug option was replaced by
       another method of pausing periodic checkpoints. (Bug
       #27588328)

     * InnoDB: A transaction on a table with a spatial index
       defined on a column with a spatial reference identifier
       (SRID) was able to insert into an area selected for
       update by another transaction. (Bug #27577612)

     * InnoDB: A foreign key constraint name was duplicated
       during a rename table operation, causing a failure during
       later query execution. (Bug #27545888)

     * InnoDB: A Serialized Dictionary Information (SDI)
       deletion failure raised an assertion. (Bug #27493634)

     * InnoDB: A server exit occurred after freeing large object
       (LOB) index entries during a LOB purge or rollback. (Bug
       #27419474)

     * InnoDB: In a function called before the execution of a
       statement in a stored procedure, a read and write
       operation on trx->lock.start_stmt was not protected by a
       mutex. (Bug #27325898)

     * InnoDB: The INFORMATION_SCHEMA.FILES and
       INFORMATION_SCHEMA.INNODB_TABLESPACES tables did not show
       the actual undo tablespaces that were present in the
       MySQL instance. Only the two default undo tablespaces
       were shown. (Bug #26820406)

     * InnoDB: An error occurred during a DDL operation due to a
       mismatch in a REDUNDANT row format calculation that
       determines the length of the online log. (Bug #26375771)

     * InnoDB: Enabling innodb_undo_log_truncate negatively
       affected transaction processing performance. Instead of
       performing two checkpoints during an undo tablespace
       truncate operation, pages that belong to the tablespace
       file are now flushed from disk. (Bug #26322656)

     * InnoDB: A helper class was introduced to improve
       performance associated with reading from secondary keys
       when there are multiple versions of the same row.
       Thanks to Domas Mituzas for the contribution. (Bug
       #25540277, Bug #84958)

     * InnoDB: The location of the Innodb Merge Temp File that
       reported by the wait/io/file/innodb/innodb_temp_file
       Performance Schema instrument was incorrect. (Bug
       #21339079, Bug #77519)

     * Partitioning: When a CREATE TABLE ... PARTITION BY ...
       statement failed due to an invalid partition definition,
       the server did not remove any partition files which might
       have been created prior to encountering the invalid
       PARTITION clause. (Bug #27798708)
       References: See also: Bug #88043, Bug #26945644.

     * Partitioning: It was possible to perform FLUSH TABLES FOR
       EXPORT on a partitioned table created with
       innodb_file_per_table=1 after discarding its tablespace.
       Attempting to do so now raises ER_TABLESPACE_DISCARDED.
       (Bug #95045, Bug #27903881)
       References: See also: Bug #80669, Bug #22899690.

     * Partitioning: An extraneous row lock was imposed by an
       update to a partitioned InnoDB table. (Bug #87253, Bug
       #26553164)

     * Replication: When a group member resumes after being
       suspended for some time and is not able to process all
       pending messages, it enters the ERROR state. However, the
       remaining members see it as UNREACHABLE, and wait until
       the member's suspicion expires to evict it from the
       group. The behavior has now been modified and a member
       stopping due to some error tries to connect to a known
       peer to request its removal from the group, before
       installing the leave view. (Bug #28252687)

     * Replication: When a replication slave is restarted by a
       START SLAVE statement, the columns in the Performance
       Schema table replication_applier_status_by_worker
       beginning APPLYING_TRANSACTION are now reset on a slave
       that is operating in single-threaded mode. These columns
       were always reset on a multi-threaded slave, because the
       existing worker threads were terminated by the statement
       and the information could not be retained. The behavior
       has now been standardized across the slave configurations
       by resetting the columns for a single-threaded slave as
       well. (Bug #28248026)

     * Replication: If Group Replication was started on server
       with an invalid group_replication_group_name, the server
       would stop unexpectedly. (Bug #28219136)

     * Replication: If a multi-threaded replication slave was
       stopped, changed to a single-threaded slave (by setting
       slave_parallel_workers > 0), and restarted, the
       Performance Schema table
       replication_applier_status_by_worker showed irrelevant
       timestamps because the old monitoring information had not
       been cleared. (Bug #28191382)

     * Replication: If the
       group_replication_recovery_retry_count variable was
       modified while the member was already making a
       reconnection attempt, the connection attempt could enter
       an infinite loop. (Bug #28092714)

     * Replication: When the binlog_group_commit_sync_delay
       system variable is set to a wait time to delay
       synchronization of transactions to disk, and the
       binlog_group_commit_sync_no_delay_count system variable
       is also set to a number of transactions, the MySQL server
       exits the wait procedure if the specified number of
       transactions is reached before the specified wait time is
       reached. The server manages this process by checking on
       the transaction count after a delta of one tenth of the
       time specified by binlog_group_commit_sync_delay has
       elapsed, then subtracting that interval from the
       remaining wait time.
       If rounding during calculation of the delta meant that
       the wait time was not a multiple of the delta, the final
       subtraction of the delta from the remaining wait time
       would cause the value to be negative, and therefore to
       wrap to the maximum wait time, making the commit hang.
       The data type for the remaining wait time has now been
       changed so that the value does not wrap in this
       situation, and the commit can proceed when the original
       wait time has elapsed. Thanks to Yan Huang for the
       contribution. (Bug #28091735, Bug #91055)

     * Replication: In debug builds, an assertion failed because
       more than 255 collations are now available in MySQL. (Bug
       #28015761)

     * Replication: An assertion was raised in debug builds
       because the MySQL server recorded a GTID consistency
       violation, but did not remove the record after the
       relevant statement failed to execute successfully. The
       handling of this situation has now been improved to
       ensure that the server checks at the end of a transaction
       whether a GTID consistency violation was produced by a
       failed statement, and if this is the case, restores the
       previous GTID consistency state. (Bug #27903831, Bug
       #90551)

     * Replication: The group_replication_exit_state_action
       variable enables you to specify what action is taken if a
       member involuntarily leaves the group, but when starting
       a server with group_replication_start_on_boot enabled the
       group_replication_exit_state_action variable was being
       ignored during the following scenarios:

          + valid number of group members was exceeded

          + incompatible configuration of the member system
            variables (various)

          + the joining member had more transactions than the
            group

          + the joining member's version was not compatible with
            the group
       (Bug #27881311)

     * Replication: With GTIDs in use for replication,
       transactions including statements that caused a parsing
       error (ER_PARSE_ERROR) could not be skipped manually by
       the recommended method of injecting an empty or
       replacement transaction with the same GTID. This action
       should result in the slave identifying the GTID as
       already used, and therefore skipping the unwanted
       transaction that shared its GTID. However, in the case of
       a parsing error, because the statement was parsed before
       the GTID was checked to see if it needed to be skipped,
       the replication applier thread stopped due to the parsing
       error, even though the intention was for the transaction
       to be skipped anyway.
       With this fix, the replication applier thread now ignores
       parsing errors if the transaction concerned needs to be
       skipped because the GTID was already used. Note that this
       behavior change does not apply in the case of workloads
       consisting of binary log output produced by mysqlbinlog.
       In that situation, there would be a risk that a
       transaction with a parsing error that immediately follows
       a skipped transaction would also be silently skipped,
       when it ought to raise an error. (Bug #27638268)

     * Replication: When a RESET SLAVE statement was issued on a
       replication slave with GTIDs in use, the existing relay
       log files were purged, but the replacement new relay log
       file was generated before the set of received GTIDs for
       the channel had been cleared. The former GTID set was
       therefore written to the new relay log file as the
       PREVIOUS_GTIDS event, causing a fatal error in
       replication stating that the slave had more GTIDs than
       the master, even though the gtid_executed set for both
       servers was empty. Now, when RESET SLAVE is issued, the
       set of received GTIDs is cleared before the new relay log
       file is generated, so that this situation does not occur.
       (Bug #27636289)

     * Replication: The master's receiver thread for
       semisynchronous replication held a mutex while reading
       acknowledgements from slaves, but the same mutex was
       required to add or remove a semisynchronous slave,
       causing those operations to be delayed by the
       acknowledgement activity. The issue has now been fixed by
       not acquiring the mutex to read the acknowledgements from
       slaves. (Bug #27610678, Bug #89370)

     * Replication: In code for replication slave reporting, a
       rare error situation raised an assertion in debug builds,
       but in release builds, returned leaving a mutex locked.
       The mutex is now unlocked before returning in this
       situation. Thanks to Zsolt Parragi for the patch. (Bug
       #27448019, Bug #89421)

     * Replication: Entries in the relay log info log (the
       slave_relay_log_info table) for the Group
       Replication-specific channels group_replication_applier
       and group_replication_recovery were not being cleared by
       a RESET SLAVE or RESET SLAVE ALL command. (Bug #27411175)

     * Replication: Automatic retrying of transactions on a
       replication slave, as specified by the
       slave_transaction_retries system variable, was taking
       place even if the transaction had a non-temporary error
       that would repeat on retrying or that indicated wider
       issues. Now, transactions are only automatically retried
       if there is either no error, or an error that is only
       temporary. (Bug #27373559, Bug #89143)

     * Replication: When FLUSH statements for specific log types
       (such as FLUSH SLOW LOGS) resulted in an error, the
       statements were still written to the binary log. This
       stopped replication because the error had occurred on the
       master, but did not occur on the slave. MySQL Server now
       checks on the outcome of these FLUSH statements, and if
       an error occurred, the statement is not written to the
       binary log. (Bug #24786290, Bug #83232)

     * Replication: The PASSWORD() function, which produces a
       hash of the password, was deprecated in MySQL 5.7 and
       removed in MySQL 8.0. When a SET PASSWORD statement that
       used this function was replicated from a MySQL 5.6 master
       to a MySQL 5.7 slave, or from a MySQL 5.7 master with the
       log_builtin_as_identified_by_password system variable set
       to ON to a MySQL 5.7 slave, the password hash was itself
       also hashed before being stored on the slave. The issue
       has now been fixed and the replicated password hash is
       stored as originally passed to the slave. (Bug #24687073)

     * Replication: If an ORDER BY clause was used in retrieving
       records from certain Performance Schema tables relating
       to replication, an empty set was returned. The issue has
       now been fixed. (Bug #22958077, Bug #80777)

     * Replication: When replication channels are used on a
       slave for multi-source replication, a START SLAVE
       statement that does not specify an individual channel (so
       without the FOR CHANNEL clause) should start the I/O
       thread and the SQL thread for all of the channels on the
       replication slave. However, if a RESET SLAVE statement
       was used on such a slave, a subsequent START SLAVE
       statement did not start the non-default channels. Now,
       replication channels that are deinitialized as a result
       of a RESET SLAVE statement, rather than as a result of an
       error in the initialization process, are identified and
       are restarted by a START SLAVE statement that applies to
       all channels. (Bug #22809607)

     * Replication: Issuing RESET SLAVE on a replication slave
       does not change any replication connection parameters
       such as master host, master port, master user, or master
       password, which are retained in memory. However, these
       connection parameters are reset if you issue RESET SLAVE
       ALL. Previously, if the slave mysqld was restarted
       immediately after issuing RESET SLAVE (including a server
       crash as well as a deliberate restart), the connection
       parameters were reset as if RESET SLAVE ALL had been
       used.
       Now, when master_info_repository=TABLE is set on the
       server (which is the default from MySQL 8.0), replication
       connection parameters are preserved in the crash-safe
       InnoDB table mysql.slave_master_info as part of the RESET
       SLAVE operation. They are also retained in memory. In the
       event of a server crash or deliberate restart after
       issuing RESET SLAVE but before issuing START SLAVE, the
       replication connection parameters are retrieved from the
       table and reused for the new connection.
       If master_info_repository=FILE is set on the server
       (which is the default in MySQL 5.7), replication
       connection parameters are only retained in memory, so the
       behavior remains the same as previously. If the slave
       mysqld is restarted due to a server crash or a deliberate
       restart immediately after issuing RESET SLAVE, the
       connection parameters are lost. In that case, you must
       issue a CHANGE MASTER TO statement after the server start
       to respecify the connection parameters before issuing
       START SLAVE.
       If you want to reset the connection parameters
       intentionally, you need to use RESET SLAVE ALL, which
       clears the connection parameters. In that case, you must
       issue a CHANGE MASTER TO statement after the server start
       to specify the new connection parameters. (Bug #20280946)

     * Replication: Compilation warnings related to unused
       functions in xdr_utils have been reduced. Thanks to Zsolt
       Parragi for the patch. (Bug #91071, Bug #28099963)

     * Replication: When group_replication_group_seeds contained
       a DNS based entry which resolved to its own local
       address, Group Replication could not start. (Bug #90483,
       Bug #27882096, Bug #28074929)

     * Replication: Issuing START GROUP_REPLICATION and then
       forcibly stopping the mysqld process, for example using
       control-C, could result in an unexpected halt of the
       server. (Bug #90457, Bug #27873419)

     * Microsoft Windows: An error now is written to the server
       log when the presence of the NO_AUTO_CREATE_USER value
       for the sql_mode option in the options file prevents a
       MySQL 8.0 server from starting. (Bug #28061945, Bug
       #90967)

     * Microsoft Windows: On Windows, uninstallation of the
       MySQL Server MSI package through MySQL Installer produced
       a spurious popup window. (Bug #27463864)

     * Microsoft Windows: On Windows, DBUG_ABORT did not print
       the custom stack trace and other information. (Bug
       #21383530)

     * JSON: The server did not reject creation of a table with
       a generated column in which the generated column used
       JSON_TABLE(), even though subqueries, parameters,
       variables, stored functions, and user-defined functions
       are not permitted in expressions for generated columns.
       The server now checks more aggressively to make sure any
       of the disallowed constructs (including JSON_TABLE()) are
       rejected for use in such expressions. (Bug #28518485)

     * JSON: SELECT ... FROM JSON_TABLE() sometimes failed with
       a permissions error for a user other than MySQL root.
       This issue could also occur when such a query was used as
       the basis for a view, and a SELECT from the view failed.
       (Bug #28255453, Bug #27923406)
       References: See also: Bug #27189940.

     * JSON: The JSON_TABLE() function subjected integer values
       greater than or equal to 2^31 to wraparound. For example,
       the query SELECT id FROM
       JSON_TABLE('[{"id":"2147483648"}]', '$[*]' COLUMNS (id
       BIGINT UNSIGNED PATH '$.id')) AS json returned
       -2147483648. (Bug #27856835)

     * JSON: In some contexts, the NULLIF() function returned
       its first argument as a boolean value rather than its
       actual type. This was noticed when the result of this
       function was used as an argument to JSON_ARRAYAGG() or
       JSON_OBJECTAGG(), but could have occurred in other cases
       in which NULLIF() was used in a similar fashion. (Bug
       #90833, Bug #28007237)

     * JSON: When a JSON document which contained binary data
       was converted to base-64 encoded text for display,
       newline characters in the encoded string were not
       properly escaped, so that the text representation could
       not be parsed as JSON, and was thus truncated, corrupted,
       or both. Now MySQL makes sure that any newline characters
       in the encoded string are escaped. (Bug #90503, Bug
       #27891359)

     * On the Fedora 29 platform, OpenSSL 1.0.x is used to build
       packages because 1.1.1 support is not ready. If you build
       MySQL from source, it is recommended that you build using
       the compat-openssl10-devel package. (Bug #28737143)

     * On the Fedora 29 platform, upgrading from MariaDB to
       MySQL 8.0.13 failed due to missing obsoletes. (Bug
       #28727698)

     * MySQL binary distributions for SLES 12 now are built
       using GCC 7. The lowest supported GCC version on this
       platform is now 5.3 (previously 4.8.5). (Bug #28542723)

     * Trying to add a functional index on a subquery should not
       be possible, and caused the server to hit an assertion
       when trying to resolve the indexed expression. Now in
       such cases, the expression is disallowed, and the servers
       returns an appropriate error message. (Bug #28526493)

     * Added a range check when performing calculations with
       exponents. (Bug #28505423)

     * CMAKE -DWITHOUT_SERVER=1 resulted in build errors. (Bug
       #28501563, Bug #92011)

     * When a prefix index was specified with a length of 8
       bytes, the Sub_part column in the output of SHOW INDEXES
       was NULL. (Bug #28499603)

     * Compilation failed for GCC 8 with MySQL configured to use
       some system libraries. (Bug #28471072, Bug #91914)

     * For debug builds, if the server bootstrapping phase
       failed, missing cleanup code caused an assertion to be
       raised. (Bug #28435378, Bug #91847)

     * Numeric ranges in MySQL builds could differ between the
       ARM and Intel x64 platforms. (Bug #28401869)

     * For mysqldump --tables output, file names now always
       include a .txt or .sql suffix, even for file names that
       already contain a dot. Thanks to Facebook for the
       contribution. (Bug #28380961, Bug #91745)

     * Concurrent INSERT and SELECT statements on a MERGE table
       could result in a server exit. (Bug #28379285)

     * On SLES 15, upgrading from MariaDB packages to MySQL
       packages failed due to incorrect obsoletes information.
       (Bug #28292138)

     * The data dictionary auto releaser now allocates maps for
       data dictionary object types dynamically. Also, maps were
       added for column statistics and resource groups used in
       size calculations and object removal, and an auto
       releaser was added for ANALYZE TABLE operations. (Bug
       #28245522, Bug #91420)

     * It was possible for a UNION query that mixed different
       character sets to fail with a spurious error. (Bug
       #28237675)
       References: This issue is a regression of: Bug #83895,
       Bug #25123839.

     * CHECK TABLE ... FOR UPGRADE on temporary tables could
       raise an assertion. (Bug #28220374)
       References: This issue is a regression of: Bug #24741307.

     * A divide-by-zero error could occur in the range
       optimizer. (Bug #28214186)

     * Due to a GCC 8 bug, recursion in foreign key checks could
       exhaust stack space. (Bug #28200774)

     * When sql_mode was set to the empty string, queries of the
       form SELECT CONCAT( FORMAT(LPAD(char,2,''), 1) ) were not
       handled properly; the same was also true for
       similarly-formed queries using RPAD() in place of LPAD().
       (Bug #28197977)

     * Non-privileged users could change their own account
       password history and reuse properties. (Bug #28191838)

     * The OpenSSL 1.1 OPENSSL_malloc_init() call did not work
       well on Windows. To address this, alternative allocation
       wrappers are used instead of the defaults from OpenSSL.
       Consequently, OpenSSL memory instrumentation is turned
       off. (Bug #28179051)

     * Allocation of certain object types during data dictionary
       lookups resulted in a stack buffer overflow. (Bug
       #28176453)

     * An internal server operation that attempted to perform a
       commit while fetching table statistics from the
       INFORMATION_SCHEMA could raise an assertion. (Bug
       #28165060)

     * Certain stored procedures could cause a server exit. (Bug
       #28156802)

     * Output for CREATE USER statements could differ in the
       general query log and audit log. (Bug #28147710)

     * For UPDATE and DELETE statements that produce an error
       due to sql_safe_updates being enabled, the error message
       was insufficiently informative. The message now includes
       the first diagnostic that was produced, to provide
       information about the reason for failure. For example,
       the message may indicate that the
       range_optimizer_max_mem_size value was exceeded or type
       conversion occurred, either of which can preclude use of
       an index.
       Additionally: (1) Using EXPLAIN for such statements does
       not produce an error, enabling users to see from EXPLAIN
       plus SHOW WARNINGS output why an index is not used. (2)
       For multiple-table deletes and updates, an error is
       produced with safe updates enabled only if any target
       table uses a table scan. (Bug #28145710, Bug #91080)

     * MySQL Server and test RPM packages were missing
       perl-Data-Dumper as a dependency. (Bug #28144933, Bug
       #72926)

     * Server startup could fail if a service needed by a
       component was not yet initialized. (Bug #28142250)

     * SHOW CREATE TABLE could omit foreign key RESTRICT
       options. This in turn could cause foreign key RESTRICT
       options to be lost from tables dumped with mysqldump and
       restored from the dump file. (Bug #28122781, Bug #91110)

     * The mysql client was slow to import large multiple-line
       statements in batch mode. Memory allocation is now more
       efficient for this situation. Thanks to Sinisa
       Milivojevic for the patch. (Bug #28116512, Bug #85155)

     * The SUM() and AVG() functions did not handle correctly a
       string argument used with a window function. (Bug
       #28105241)

     * Excessive nesting of geometry collections caused the
       server to exhaust stack space. The server now raises an
       error if there is a danger of stack overrun. (Bug
       #28100563)

     * For the mysql client, the -b short option was associated
       with two long options, --no-beep and --binary-as-hex. The
       -b option now is associated only with --no-beep. (Bug
       #28093271)

     * For a table with an auto-increment primary key,
       concurrent ALTER TABLE ... ADD ... VIRTUAL and INSERT
       statements could lead to duplicate-key errors. (Bug
       #28089240)

     * Handling of floating-point values by SUM() was improved.
       (Bug #28080199)

     * Some expressions using ST_Simplify() could cause a server
       exit. (Bug #28079969)

     * Testing on a UBSan-enabled build returned a "member call
       on null pointer of type 'struct Event_db_repository'"
       error. (Bug #28066155)

     * The WITH_GMOCK CMake option did not handle Windows path
       names properly. (Bug #28061409, Bug #90964)

     * INFORMATION_SCHEMA queries that attempted to cache table
       statistics could raise a debugging assertion. (Bug
       #28035207)

     * If roles were assigned to accounts, certain sql_mode
       settings could cause the server to be unable to start.
       (Bug #28030423)

     * Group lookups for LDAP authentication plugins could fail
       if the user had insufficient privileges. Now, group
       search operations bind again using root credentials if
       those are available. (Bug #28016008)

     * ANALYZE TABLE ... UPDATE HISTOGRAM statements produced by
       mysqldump contained a syntax error. (Bug #28014376, Bug
       #90846)

     * Generated columns having indexes and that used a string
       function were not always populated correctly. (Bug
       #27973409)

     * Fixed-length sort keys, such as those used by priority
       queues, that fit exactly were assumed to have failed.
       (Bug #27970481, Bug #92448, Bug #28654343)

     * For an empty result, REPLACE() sometimes returned a null
       string rather than an empty string. (Bug #27960921)

     * Dropping a table that was created with a user-defined
       collation no longer available could cause a server exit.
       (Bug #27952999)

     * Joining the INFORMATION_SCHEMA REFERENTIAL_CONSTRAINTS
       and TABLE_CONSTRAINTS tables on the CONSTRAINT_NAME
       failed because the column collations differed. (Bug
       #27945704, Bug #90690)

     * Some operations on DECIMAL values could cause a server
       exit. (Bug #27942277)

     * Stored program definitions in mysqldump dump files
       sometimes included the NO_AUTO_CREATE_USER SQL mode.
       Because that mode has been removed in MySQL 8.0, loading
       such a dump file into a MySQL 8.0 server failed.
       mysqldump now removes NO_AUTO_CREATE_USER from the
       definition of dumped stored programs. (Bug #27931181, Bug
       #90624)

     * Very long table keys were handled incorrectly on
       replication slaves. (Bug #27930505)

     * mysqld did not determine its installation directory
       correctly if that directory was the last one listed in
       $PATH. (Bug #27922896)

     * During server startup/shutdown, PID files could be
       mishandled. (Bug #27919254)

     * On rare occasions, setting a savepoint could raise an
       assertion. (Bug #27898591)

     * Runtime errors could occur for calls to copy_integer().
       myfunc_int(), mysql_sys_var_int(), or thd_killed(); for
       calls to MyISAM sorting functions; or for values outside
       the range of representable values of type unsigned long
       long. (Bug #27894901, Bug #90515, Bug #27871951, Bug
       #27918095, Bug #90609, Bug #27937522, Bug #90661, Bug
       #27978325, Bug #27962900)

     * mysql_install_plugin failed to report plugin-specific
       errors if the server was unable to store plugin metadata
       in the data dictionary. (Bug #27893406)

     * ssl_fips_mode cannot be set to ON unless the OpenSSL
       requirements are satisfied, but a failed attempt still
       resulted in the value being displayed as ON. (Bug
       #27891890)

     * The symbol for the mysql_result_metadata() C API function
       was not exported by the client library on Windows. (Bug
       #27868095)

     * For InnoDB tables, self-referencing foreign keys could be
       created, causing server misbehavior. (Bug #27864515)

     * A UNION query mixing different character sets produced
       invalid output when performed in a prepared statement or
       a stored procedure. (Bug #27849293)

     * Debian packages were missing a dependency for
       libcurl-dev. (Bug #27844465)

     * --help output for client programs did not include the
       current --ssl-fips-mode value. (Bug #27838966)

     * A runtime error could occur for calls to
       Derived_key_comp(). (Bug #27830679)

     * For MEMORY tables, memory overflow errors could occur.
       (Bug #27799513)

     * When converting from a BLOB (or TEXT) type to a smaller
       BLOB (or TEXT) type, no warning or error was reported
       informing about the truncation or data loss. Now an
       appropriate error is issued in strict SQL mode and a
       warning in nonstrict SQL mode. (Bug #27788685, Bug
       #90266)

     * For debug builds, my_strnxfrm_unicode_full_bin() could
       raise an assertion. (Bug #27752619)

     * In builds with Undefined Behavior Sanitizer enabled,
       signed integer overflow could occur in GIS calculations.
       (Bug #27751479, Bug #27744399, Bug #27811282)

     * It was possible in some cases for the internal function
       regexp::EvalExprToCharset() to bind a reference to a
       misaligned address. (Bug #27743722)

     * The severity of messages produced by the server about
       being unable to read key files has been escalated from
       INFORMATION to WARNING. (Bug #27737195)

     * No temporary table field was created for an expression
       using window functions combined with a rollup, causing
       queries containing these to fail. (Bug #27735167)

     * The expression FIND_IN_SET( JSON_UNQUOTE(
       JSON_SET('{}','$','') ), 1) was not evaluated properly.
       (Bug #27731699)

     * Failure to create a temporary table during a MyISAM query
       could cause a server exit. Thanks to Facebook for the
       patch. (Bug #27724519, Bug #90145)

     * parser_max_mem_size was ineffective when parsing stored
       program definitions. (Bug #27714748)

     * A BETWEEN clause comparing negative values could lead to
       erroneous results. (Bug #27691347)

     * These scripts are no longer included in RPM packages
       (they are unnecessary because they are compiled into the
       mysqld binary): fill_help_tables.sql,
       mysql_sys_schema.sql, mysql_system_tables.sql,
       mysql_system_tables_data.sql, mysql_system_users.sql.
       (Bug #27672991)

     * Unique::io_cache was not cleaned up properly when
       restarting an index merge operation, leading to an
       assertion in debug builds. (Bug #27599292)

     * Using a binary or hexadecimal literal value in a ENUM
       column resulted in a string type with bytes not permitted
       by the data dictionary character set. (Bug #27592803)

     * It was possible for CONVERT() to fail under the following
       conditions:
       The size of the result of the conversion was greater than
       max_allowed_packet
       sql_mode was '' (that is, empty).
       The character set of the result differed from
       character_set_connection (Bug #27592714)

     * Use of ENUM or SET fields with JSON_TABLE() could result
       in unexpected behavior. (Bug #27571251)

     * Host name resolution errors could cause the audit_log
       plugin to fail. (Bug #27567003)

     * Unsuccessful connection attempts were not being written
       to the error log when log_error_verbosity=3. (Bug
       #27539838)

     * Persisted system variables with a value of NULL were
       written to mysqld-auto.cnf incorrectly. (Bug #27512616)

     * An earlier code cleanup caused FEDERATED storage engine
       failures. (Bug #27493633, Bug #89537)
       References: This issue is a regression of: Bug #25943754.

     * Setting max_execution_time sometimes had no effect when
       used with full-text search. (Bug #27155294)

     * An attempted read of an uncommitted transaction raised an
       assertion. (Bug #26876608)

     * ALTER TABLE ... REORGANIZE PARTITION ... could result in
       incorrect behavior if any partition other than the last
       was missing the VALUES LESS THAN part of the syntax. (Bug
       #26791931)

     * In some cases when ER_DATA_TOO_LONG was the appropriate
       error, ER_TRUNCATED_WRONG_VALUE_FOR_FIELD was reported
       instead. (Bug #26475237, Bug #87100)

     * A last_checked_for_upgrade column that stores the current
       server version number was added to the mysql.tables data
       dictionary table to track successful CHECK TABLE ... FOR
       UPGRADE operations. This data was previously stored in
       .frm files to avoid rechecking tables unnecessarily. (Bug
       #24741307, Bug #83169)

     * A range check for the product of a signed and unsigned
       integer could be performed incorrectly. (Bug #17081376,
       Bug #69715)

     * Specifying the maximum possible value for a YEAR column
       failed when expressed as a real constant such as
       2155.0E00 or 2.15E3. (Bug #91226, Bug #28172538)

     * Prevented potential member access within a null pointer
       of type SELECT_LEX. (Bug #90689, Bug #27945614)

     * The base used for calculation of line numbers reported in
       warnings generated by SELECT statements has been changed
       from the number of input rows read to the actual row
       numbers seen by the user. For statements using GROUP BY,
       this number is now based on the number of aggregate
       groupings. (Bug #90667, Bug #27938507)

     * Estimates contained by histograms for the number of
       distinct values in each bucket, which can be employed to
       estimate the number of distinct values in a table, can
       now be used by the Optimizer's histograms::Histogram
       interface. (Bug #90465, Bug #27872281)

     * Selecting from the INFORMATION_SCHEMA.KEYWORDS table
       failed when no default database had been selected. (Bug
       #90160, Bug #27729859)

     * ANALYZE TABLE UPDATE HISTOGRAM failed to return an error
       condition to the client when lock_wait_timeout was
       exceeded during statement processing. (Bug #89738, Bug
       #27574375)

     * It was possible to create a table t having a generated
       column g and then to execute ALTER TABLE t ALTER COLUMN g
       SET DEFAULT ...; attempting to set the default for a
       generated column in this fashion now fails with Error
       1221 Incorrect usage of DEFAULT and generated column.
       This is the same behavior as for a similar CREATE TABLE
       statement. (Bug #88619, Bug #27164393)

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Community Server 8.0.13 has been released (part 2/2)
2187
October 22, 2018 08:42AM


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.