Bugs Fixed

     * Important Change: The following changes are made to the
       PERIOD_ADD() and PERIOD_DIFF() functions:

          + A period value used with one of these functions may
            not be negative.

          + The month part of a period value may not be equal to
       A period value used with one of these functions for which
       at least one of these conditions is true now causes the
       function to fail with an error. (Bug #27004699, Bug

     * Important Change: The LEAST() and GREATEST() functions no
       longer attempt to infer a context for their arguments
       from expressions in which they are used. For example,
       LEAST('11', '45', '2') returns '11', but LEAST('11',
       '45', '2') + 0 treated the function arguments as integers
       rather than as strings, and returned 2. Now these
       functions always evaluate their arguments strictly
       according to type, and any data type coercion due to
       their inclusion in an expression is performed only on the
       result returned by the function. This means that the
       expression LEAST('11', '45', '2') + 0 now evaluates to
       '11' + 0, and thus to the integer value 11.
       This change has been made due to the following

          + Rules for deriving the context were not always clear
            or consistent.

          + The results of these functions when used in
            expressions were not consistent with the results of
            COALESCE(), or of a UNION query.
       Applications that use these functions within expressions
       should be checked to make sure that they do not depend on
       the previous behavior, and updated if they do so. (Bug
       #83895, Bug #25123839)

     * InnoDB: An ALTER TABLE operation that added a foreign key
       constraint referencing a table with generated virtual
       columns raised an assertion. (Bug #27189701)

     * InnoDB: Concurrent XA transactions that ran successfully
       to the XA prepare stage on the master conflicted when
       replayed on the slave, resulting in a lock wait timeout
       in the applier thread. The conflict was due to the GAP
       lock range which differed when the transactions were
       replayed serially on the slave. To prevent this type of
       conflict, GAP locks taken by XA transactions in READ
       COMMITTED isolation level are now released (and no longer
       inherited) when XA transactions reach the prepare stage.
       (Bug #27189701, Bug #25866046)

     * InnoDB: A DROP DATABASE operation raised an assertion due
       to a missing general tablespace data file. (Bug

     * InnoDB: On Windows, an operation that altered a table
       partition raised an assertion. The table name was not
       parsed correctly. (Bug #27075816)

     * InnoDB: A TRUNCATE TABLE operation on a temporary table
       raised an assertion. (Bug #27073280)

     * InnoDB: A call to a recovery-related function during the
       post-DDL phase of a DDL operation raised an assertion.
       (Bug #27041487, Bug #88263)

     * InnoDB: A table with a 64-character foreign key name
       caused an upgrade failure. Foreign key names up to 64
       characters in length should be permitted. (Bug #27014308,
       Bug #88196)

     * InnoDB: The InnoDB recovery process failed with a
       tablespace size error for a compressed table that was
       upgraded from MySQL 5.7 to MySQL 8.0.
       The tablespace file for a compressed table is now created
       using the physical page size instead of the InnoDB page
       size, which makes the initial size of a tablespace file
       for an empty compressed table smaller than in previous
       MySQL releases. (Bug #27014083, Bug #88195)

     * InnoDB: A typo was corrected in an InnoDB recovery
       message. Thanks to Daniƫl van Eeden for the patch. (Bug
       #27010613, Bug #88185)

     * InnoDB: An orphan .frm file caused an upgrade failure,
       and subsequent upgrade attempts were unsuccessful due to
       a full-text search auxiliary table that was renamed
       during the first upgrade attempt. (Bug #26995951)

     * InnoDB: Unnecessary tablespace fetch and cache update
       operations caused a server startup delay. (Bug #26995951)
       References: This issue is a regression of: Bug #26832347.

     * InnoDB: Workarounds introduced to address conflicting
       serialized dictionary information (SDI) inserts during
       concurrent CREATE TABLE operations were removed. (Bug
       References: See also: Bug #26539665.

     * InnoDB: A "no space left on device" error reported an
       invalid error message. (Bug #26960345)

     * InnoDB: During a fast shutdown, InnoDB attempted to write
       dynamic metadata to the data dictionary after files were
       closed, resulting in an initialization failure due
       pending I/O on the data dictionary tablespace. (Bug

     * InnoDB: A stack overflow error was encountered on startup
       after upgrading to MySQL 8.0.4 due to repeated attempts
       to load an evicted InnoDB system table. (Bug #26945437,
       Bug #88042)

     * InnoDB: Importing a compressed table raised an assertion.
       The operation used the clustered index of the table
       instead of the serialized dictionary information (SDI)
       index to transform SDI pages. (Bug #26938297)

     * InnoDB: In debug builds, failed temporary table creation
       during a REPLACE operation raised an invalid assertion.
       (Bug #26919378, Bug #26958868)

     * InnoDB: DROP DATABASE failed if database tables were
       created in a general tablespace. General tablespace flags
       were registered incorrectly causing the serialized
       dictionary information (SDI) operation to fail. (Bug

     * InnoDB: With binary logging enabled, an ALTER TABLESPACE
       ... RENAME operation failed with a "cannot find space"
       error. (Bug #26832347)

     * InnoDB: An operation that failed to add an index raised
       an invalid adaptive hash index assertion. (Bug #26788968)

     * InnoDB: A valid table row type value read from the data
       dictionary raised an invalid assertion. (Bug #26773152)

     * InnoDB: Starting an upgrade with innodb_force_recovery=5
       initialized InnoDB background threads but did not exit
       the threads gracefully when an error was encountered.
       Upgrading with a nonzero innodb_force_recovery setting is
       no longer permitted. (Bug #26766632)

     * InnoDB: A failed CREATE TEMPORARY TABLE statement left an
       in-memory table object was not freed. (Bug #26765438)

     * InnoDB: InnoDB looked up the name of a virtual column in
       the wrong dict_table_t array when attempting to locate a
       qualifying index for a foreign key. (Bug #26764604)

     * InnoDB: Attachable read-write transactions that update
       the table_stats and index_stats data dictionary tables
       attempted to update the same row, causing a deadlock.
       (Bug #26762517)

     * InnoDB: During recovery, the tablespace name in an
       in-memory tablepace object was defined using the file
       name character set instead of table name character set,
       resulting in a "missing tablespace" error. (Bug

     * InnoDB: Bootstrap code did not reserve the first 1024
       table IDs for data dictionary tables. (Bug #26757227)

     * InnoDB: Multiple updates from different clients on a
       partitioned table caused an unexpected lock wait timeout
       due to an incorrectly set lock type. (Bug #26731025, Bug

     * InnoDB: An asynchronous rollback thread that attempted to
       acquire a metadata lock was interrupted, but the
       resulting error was not returned to the server. This
       issue was addressed by removing the metadata lock
       acquisition, which was not necessary for asynchronous
       Only in-memory tables were checked when opening tables
       for undo processing. The data dictionary is now checked
       as well, in case tables are not present in memory. (Bug

     * InnoDB: An assertion was raised when attempting to open a
       full-text auxiliary table with a name that was longer
       than expected. (Bug #26649020)

     * InnoDB: Data dictionary table open functions did not
       properly handle table and schema name character set
       conversion, resulting in an error during recovery. (Bug

     * InnoDB: A transaction end_stmt() function was not called
       in some ALTER TABLE ... PARTITION scenarios, resulting in
       a timeout. (Bug #26629790, Bug #25886814)

     * InnoDB: Acquiring a metadata lock on the serialized
       diction information (SDI) table during the commit phase
       of a DDL operation would fail due to a lock wait timeout
       or halting of the query. (Bug #26628126)

     * InnoDB: Redo logs for dynamic metadata updates were not
       considered when checking redo log margin. Also, in
       read-only mode, the innodb_dynamic_metadata data
       dictionary table was opened unnecessarily for writing of
       metadata from the redo log. (Bug #26589535)

     * InnoDB: An unexpected error occurred after a failed
       attempt to install the memcached plugin. (Bug #26588738)

     * InnoDB: The state of a buffer pool page was altered by
       another thread while a buffer pool resize operation was
       in progress. (Bug #26588537)

     * InnoDB: Debug functions that assert for conflicting locks
       did not account for transaction locks that are to be
       committed or rolled back. (Bug #26562371)

     * InnoDB: Variance-Aware Transaction Scheduling (VATS)
       functionality that updates the age of waiting record
       locks failed to ignore table locks, causing an assertion
       failure. (Bug #26538702)

     * InnoDB: A DDL operation that created or modified a table
       partition unintentionally altered the row format of other
       partitions, resulting in a row format mismatch. (Bug

     * InnoDB: An ALTER TABLE operation caused the server to
       halt. (Bug #26492721)

     * InnoDB: The innodb_table_stats data dictionary table was
       not updated with new partition names when renaming a
       partitioned table. (Bug #26390658, Bug #86927)

     * InnoDB: Due to a regression introduced in MySQL 8.0.0,
       the innodb_change_buffering configuration option could
       not be set dynamically. (Bug #26389442)

     * InnoDB: The online log for a freed index was accessed
       while rolling back a concurrent UPDATE statement during
       an online DDL operation. (Bug #26334475)

     * InnoDB: A REPLACE operation on a table with a secondary
       index on the prefix of a virtual column raised an
       assertion. (Bug #26330279)

     * InnoDB: Setting tmpdir to the root of a drive caused
       "Invalid (old?) table or database name" error messages to
       be printed to the error log. (Bug #26299984, Bug #86737)

     * InnoDB: A race condition occurred during an
       INFORMATION_SCHEMA query when attempting to check the
       transaction state without acquiring a transaction mutex.
       (Bug #26299705)

     * InnoDB: A FLUSH TABLES operation failed to drop an
       aborted index. While removing the table from the cache,
       the clustered index was dropped prior to checking for the
       aborted index. (Bug #26256456, Bug #86607)

     * InnoDB: For InnoDB tables, CREATE TABLE ... LIKE did not
       respect the innodb_file_per_table system variable
       setting, and SHOW CREATE TABLE displayed a TABLESPACE
       clause even though the user specified no explicit
       tablespace during table creation. (Bug #26199233, Bug

     * InnoDB: An iterative approach to processing foreign
       cascade operations resulted in excessive memory use. (Bug
       #26191879, Bug #86573)
       References: This issue is a regression of: Bug #16244691.

     * InnoDB: The lock acquisition sequence for a buffer pool
       eviction operation that evicts compressed pages was
       incorrect. (Bug #25972975)

     * InnoDB: Metadata locks were released while data
       dictionary objects were still in use. (Bug #25928984)

     * InnoDB: innochecksum returned a Valgrind error when run
       on InnoDB files with a 1K compressed page size. (Bug
       #25922124, Bug #85993)

     * InnoDB: A kill thread failed to close the socket of
       another thread that was executing a TRUNCATE TABLE
       operation, causing an assertion. (Bug #25887335, Bug

     * InnoDB: An INSERT operation on a table with a spatial
       index raised an assertion due to a failure that occurred
       during a lock conflict check. (Bug #25729649)

     * InnoDB: A debug sync point intended for user tables was
       activated for data dictionary tables. (Bug #25508568)

     * InnoDB: A server-side check was added to prevent a
       foreign key constraint from being placed on the base
       column of a generated stored column. (Bug #25339192)

     * InnoDB: Warnings that should only appear in debug builds
       of MySQL were printed to the error log when the length of
       the history list exceeded 2000000. (Bug #24296076, Bug

     * InnoDB: Attempting to reduce the buffer pool size to less
       than the buffer pool chunk size did not report a warning.
       (Bug #23590280)

     * InnoDB: A "wrong key column" error was added to address
       an unsupported index creation scenario. (Bug #22486025)

     * InnoDB: Full-text search on indexed columns that use a
       binary collation did not return case-sensitive matches.
       (Bug #21625016, Bug #78048)

     * Packaging: When trying to install MySQL Server on Fedora
       27 using the MySQL Yum repository, installation failed
       due to a conflict with the native
       mariadb-connector-c-devel package. With this fix, the
       appropriate "obsoletes" have been added for that and
       other native packages. (Bug #26963839)

     * Partitioning: When creating a partitioned table using an
       implicit tablespace, the effect is to place each
       partition in its own tablespace, with no designated
       tablespace for the table as a whole. Since serialized
       dictionary information (SDI) was stored in all
       tablespaces used by a given table, the cost of storing it
       in a table with many tablespaces became prohibitive. This
       problem is solved by including only the tablespace for
       the first partition in the set of tablespaces used to
       store the SDI. (Bug #26762973)
       References: See also: Bug #26765252.

     * Partitioning: An assertion could be raised on CREATE VIEW
       on partitioned tables when the server tried to prune
       partitions of the underlying tables. (Bug #26659699)

     * Partitioning: When renaming a partitioned table, the
       table statistics were not updated with the new partition
       names. (Bug #86074, Bug #25953183)

     * Replication; JSON: For row-based replication, partial
       updates to JSON documents were not applied if the server
       variable binlog_row_value_options=PARTIAL_JSON
       (introduced in MySQL 8.0.3) was not specified on the
       replication slave, as well as on the master. Now, a
       replication slave applies partial updates to JSON
       documents whenever these are received from the master,
       whether or not the slave has
       binlog_row_value_options=PARTIAL_JSON in its own
       settings. (Bug #26762675)

     * Replication: The function set_unknow_error() in the
       Binlog_sender class has been renamed to
       set_unknown_error(). Thanks to Simon Mudd for the fix
       (and also for the typo fix in Bug 88149). (Bug #27149075,
       Bug #88559)
       References: See also: Bug #26996065, Bug #88149.

     * Replication: When you invoke mysqld with the --initialize
       or --initialize-insecure option to initialize the data
       directory, a warning message is no longer issued
       regarding the availability of the mysql.gtid_executed
       table, which should not be available at that stage. Also,
       the message formerly issued as a warning regarding the
       generation of a new UUID is now issued as a note, because
       the generation of a new UUID is normal in that situation.
       (Bug #27115183)

     * Replication: All servers that belong to a group must have
       unique UUIDs set by server_uuid, but this was not being
       enforced by Group Replication and it was possible to add
       members with duplicated UUIDs. (Bug #27105803)

     * Replication: In MySQL 8.0.3, the default base name for
       the binary log files and index file was host_name-bin,
       using the name of the host machine. This default name was
       used if the --log-bin option was not supplied, and also
       if the --log-bin option was supplied with no string or
       with an empty string. From MySQL 8.0.4, if you do not
       supply the --log-bin option, MySQL now uses binlog as the
       default base name for the binary log files and index
       file. In releases before MySQL 8.0.3, there was no binary
       log with that configuration, so there is no
       incompatibility with existing binary logs at upgrade.
       However, for compatibility with existing binary logs from
       releases before MySQL 8.0.3, if you supply the --log-bin
       option with no string or with an empty string, the base
       name defaults to host_name-bin, using the name of the
       host machine.
       The warning messages that were previously issued at
       startup if you did not specify a binary log file name
       using the --log-bin option (ER_LOG_BIN_BETTER_WITH_NAME)
       and if you did not specify a server ID using the
       --server-id option (ER_WARN_NO_SERVERID_SPECIFIED) are
       now issued as informational messages. A warning message
       is still issued if replication is attempted with a
       nonunique server ID. (Bug #27082922)

     * Replication: During distributed recovery as part of
       joining the group, when the applier was signaling that it
       had applied all transactions, it was also blindly
       searching for partial transactions. This was to avoid
       future applier errors, which would happen if the applier
       stopped at this point. However, this search and remove
       only made sense for applier stop cases. Upon execution
       completeness it should not be done, otherwise it can
       corrupt or purge the applier relay log, which can led to
       data loss. To solve this issue, when the applier is
       waiting for execution completeness, it no longer searches
       for and removes partial transactions. (Bug #27049034)

     * Replication: Group Replication executes internal
       operations on the server during start and stop of the
       plugin, such as enabling or disabling read only mode,
       using an internal session. When this internal session was
       opened, if the total number of sessions exceeded the
       number of permitted open sessions set by max_connections,
       the operation was failing as expected but a thread was
       left behind, which later would cause issues. (Bug
       #27008102, Bug #27016552)

     * Replication: In the Gtid_log_event that precedes every
       GTID transaction in the binary log file, the
       transaction_length field used 8 bytes for transactions
       with 16777216 bytes or more, when it should have used the
       maximum permitted 9 bytes. (Bug #26993433)

     * Replication: The fix for Bug #22671846 was missing from
       MySQL version 8.0.3. (Bug #26985976)

     * Replication: The fix for Bug #26117735 (MySQL Bug #86288)
       could cause a debug assertion when running mysqlbinlog
       with the --read-from-remote-server option and the
       --rewrite-db option, depending on the database names
       specified in the rewrite rule. The issue has now been
       corrected. (Bug #26878022)

     * Replication: With MySQL compiled using yaSSL, and
       semisynchronous replication in use, a deadlock could be
       caused by incorrect handling of acknowledgement packets.
       Multiple acknowledgement packets can be read together by
       yaSSL, but the receiver thread for semisynchronous
       replication only handled the first acknowledgement packet
       seen after polling. Now, the receiver thread handles all
       acknowledgement packets that are present in the buffer.
       (Bug #26865538)

     * Replication: If Group Replication was configured to start
       on server boot when the server was being initialized
       using --initialize or --initialize-insecure, because the
       replication applier infrastructure was not initialized
       this resulted in an assertion. Now, Group Replication is
       not started when the server is being initialized. (Bug

     * Replication: In a group with heavy load, joining members
       could need to retrieve a large amount of data to gain
       synchrony with the group. If the amount of data retrieved
       exceeded the View_change packet size of 4Mb the members
       would fail to join the group and enter Error state. Now,
       the packet size is taken from slave_max_allowed_packet,
       which defaults to 1GB. Depending on the load your group
       processes, you might want to increase the packet size
       further by configuring slave_max_allowed_packet. (Bug

     * Replication: With semisynchronous replication in use, if
       RESET MASTER was issued while an active transaction was
       waiting for an acknowledgement from the slave, the count
       of waiting sessions in the
       Rpl_semi_sync_master_wait_sessions server status variable
       was incorrect after the wait was completed. (Bug

     * Replication: In a group where a joining member
       consistently received transactions, the joining member
       could sometimes not enter the online state. This was due
       to the way the incoming queue of messages was tested.
       (Bug #26731317)

     * Replication: The --log-slave-updates and
       --slave-preserve-commit-order options require binary
       logging. If you specify these options and also disable
       binary logging using the --skip-log-bin or
       --disable-log-bin option, a warning or error message is
       issued. The --skip-log-bin and --disable-log-bin options
       now disable the --log-slave-updates and
       --slave-preserve-commit-order options by default, so when
       those options are not specified, the warning or error
       message is not issued. (Bug #26666259)

     * Replication: XA ROLLBACK statements that failed because
       an incorrect transaction ID was given, could be recorded
       in the binary log with the correct transaction ID, and
       could therefore be actioned by replication slaves. A
       check is now made for the error situation before binary
       logging takes place, and failed XA ROLLBACK statements
       are not logged. (Bug #26618925, Bug #87393)

     * Replication: The thread where the Group Replication
       plugin was started was not being correctly killed. This
       made it impossible to stop or start the plugin after
       killing the thread where Group Replication was started.
       (Bug #26435775)

     * Replication: For the NDB storage engine, when the slave
       used hashing for searches of rows (which is included by
       default in the setting for the
       slave_rows_search_algorithms system variable from MySQL
       8.0.2), the table used to store the row hashes was not
       cleaned up correctly after records were removed on the
       slave. The issue was caused by a variant error value
       returned by the NDB storage engine, which has now been
       corrected to the expected value. (Bug #26434966)

     * Replication: MySQL internal administration commands that
       update replication-specific repository tables, for
       example during a replication synchronization check using
       the mysqlrplsync utility, can now bypass read locks. This
       enables such commands to execute regardless of the
       settings for the read_only and super_read_only system
       variables and the autocommit mode. (Bug #26414532, Bug

     * Replication: Changes to Group Replication variables while
       starting or stopping the plugin were not being correctly
       validated. Now, the variables can only be changed if the
       plugin is not changing state. (Bug #26372117)

     * Replication: The binary log function
       MYSQL_BIN_LOG::new_file_impl returned the error "Can't
       open file" (ER_CANT_OPEN_FILE) when it should have
       returned "Error writing file" (ER_ERROR_ON_WRITE). (Bug
       #26370868, Bug #86870)

     * Replication: When write sets are used for parallelization
       by a replication slave (as specified by the
       binlog_transaction_dependency_tracking system variable),
       the case and accent sensitivity of the database are now
       taken into account when generating the write set
       information. Previously, duplicate keys could be
       incorrectly identified as different, causing transactions
       to have incorrect dependencies and so potentially be
       executed in the wrong order. (Bug #26277771, Bug #86078)

     * Replication: When the transaction_write_set_extraction
       option was enabled, there was a risk of unnecessary
       serialization while foreign keys were gathered if
       concurrent DDL took place. Group Replication now takes
       advantage of the new Data Dictionary to interact with
       table definitions and foreign keys, which has solved this
       potential serialization. (Bug #26187850)

     * Replication: The receiver thread for semisynchronous
       replication was not able to receive acknowledgements from
       slaves that used compression of the master/slave protocol
       (slave_compressed_protocol=ON). The receiver thread now
       handles compressed acknowledgements correctly. (Bug
       #26027024, Bug #86230)

     * Replication: The mysql_reset_connection() function now
       clears the write set session history. (Bug #25950554, Bug

     * Replication: On replication slaves, in the XA_STATE field
       in the Performance Schema table
       events_transactions_current, the state of XA transactions
       was incorrectly reported as COMMITTED instead of PREPARED
       after the XA PREPARE statement was applied on the slave.
       (Bug #25940184)

     * Replication: In a multi-source replication topology, a
       memory leak could occur on the slave when
       binlog_rows_query_log_events was enabled on the master,
       and a statement already applied from another channel was
       skipped on the slave. In this situation, the instance of
       the Rows_query log event stored on the slave was not
       being deleted. The log event instance is now cleaned up
       and the memory is freed. Thanks to Vlad Lesin for his
       contribution to the patch. (Bug #25695434, Bug #85371,
       Bug #85034)

     * Replication: Queries to the Performance Schema
       replication_applier_global_filters and
       replication_applier_filters tables, which show the global
       and channel-specific replication filters configured on a
       replication slave, have been optimized so that a view is
       generated only when the filters are changed. Previously,
       a view was generated for every row that was created. (Bug

     * Replication: A memory leak was fixed in GTID-based
       replication. Memory was not being freed after the
       repository tables were updated for skipped or ignored
       events. (Bug #25656123, Bug #85251)

     * Replication: When a worker thread on a multi-threaded
       slave failed to apply a transaction on which a later
       transaction depended, the coordinator thread could begin
       scheduling the dependent transaction before being
       notified of the issue. If a STOP SLAVE request was made
       during this situation, it caused an assertion to be
       raised in debug builds. (Bug #25585436)

     * Replication: When
       group_replication_enforce_update_everywhere_checks=ON the
       Group Replication plugin checks if there are foreign key
       cascades and disallows updates to such tables. However
       SET NULL operations were not being checked, which could
       cause data inconsistency. Now, when
       operations on child tables are blocked if the table has a
       SET NULL option configured. (Bug #25404162)

     * Replication: On Windows, errors generated by Group
       Replication now contain the detailed error message rather
       than just the error number. (Bug #24918678)

     * Replication: With statement-based replication in use, if
       an UPDATE or DELETE statement was used inside an XA
       transaction ending with XA COMMIT ONE PHASE, and the
       statement did not affect any rows, a replication error
       occurred. An XA END statement was not written to the
       binary log, so slave servers identified the XA
       transaction as still being active at the time of the
       commit request. The required XA END statement is now
       written even if the transaction affected no rows. (Bug
       #24812958, Bug #83295)

     * Replication: Replication clients no longer enable LOCAL
       capability for LOAD DATA statements, because they do not
       use LOAD DATA LOCAL statements. (Bug #24763131)

     * Replication: The behavior of mixed-format replication
       (binlog_format=MIXED) has changed with regards to
       temporary tables. Previously, when mixed-format binary
       logging was in use, if a statement was logged by row and
       the session that executed the statement had any temporary
       tables, all subsequent statements were treated as unsafe
       and logged in row-based format until all temporary tables
       in use by that session were dropped. Also, on a
       replication slave with log_slave_updates enabled,
       row-based logging was incorrectly continued across all
       subsequent sessions for the duration of the connection,
       as reported in the bug.
       Now, when mixed binary logging format is in use,
       statements that exclusively use temporary tables are not
       logged. Statements that involve a mix of temporary and
       nontemporary tables are logged on the master only for the
       operations on nontemporary tables, and the operations on
       temporary tables are not logged. The exception is if the
       creation of a temporary table was recorded in the binary
       log using statement-based format. In this case, a DROP
       TEMPORARY TABLE IF EXISTS statement is logged on the
       master when the temporary table is dropped.
       With this change in behavior, the remaining statements in
       the session that do not involve temporary tables no
       longer need to be treated as unsafe. The safe statements
       are now logged in statement-based format, and the unsafe
       statements are logged in row-based format, according to
       the normal behavior for mixed format replication,
       regardless of the presence of temporary tables in the
       session. Also, the issue reported in the bug has been
       fixed so that subsequent sessions using the connection
       now use the appropriate logging format for the session,
       regardless of the format used by earlier sessions.
       When binlog_format is ROW or STATEMENT, the behavior
       remains as before. For row-based binary logging format,
       operations on temporary tables are not logged, with the
       exception of the DROP TEMPORARY TABLE IF EXISTS statement
       as for mixed format. For statement-based binary logging
       format, operations on temporary tables are logged on the
       master and replicated on the slave, provided that the
       statements involving temporary tables can be logged
       safely using statement-based format.
       binlog_format=STATEMENT is now the only logging mode in
       which temporary tables are replicated on the slave.
       You cannot now change the binlog_format setting from ROW
       or MIXED to STATEMENT at runtime, because any CREATE
       TEMPORARY TABLE statements will have been omitted from
       the binary log in the previous mode. You can still switch
       from STATEMENT to ROW or MIXED format, even when
       temporary tables have been created.
       Thanks to George Lorch and Laurynas Biveinis from Percona
       for the patch. (Bug #18843730, Bug #72475)

     * Replication: Regardless of the number of virtual IPs
       configured on a machine, Group Replication could access
       only the first 12 addresses. (Bug #86772, Bug #26324852)

     * Replication: The delayed initialization mechanism used
       for server starts has been improved. Now, it only blocks
       connections until the server is in read mode. (Bug
       #86271, Bug #26037344)
       References: See also: Bug #84731, Bug #25475132.

     * Replication: When a primary member, for example the
       primary in single-primary group or in a multi-primary
       group, which also had asynchronous replication channels
       feeding data into it was stopped, the asynchronous
       channels would continue applying changes. Although
       super_read_only was being set when STOP GROUP_REPLICATION
       was issued, this did not stop any running asynchronous
       replication channels which were already running. This
       meant that changes could be made locally on the member,
       and that the asynchronous replication channels had to be
       stopped manually. Now when Group Replication stops,
       either due to an error or when STOP GROUP_REPLICATION is
       issued, all asynchronous replication channels are
       stopped. (Bug #86222, Bug #26024253)

     * Replication: The logging of Group Replication has been
       improved. Now logging includes information when a member
       joins or leaves, when the view changes, and so on. (Bug
       #84798, Bug #25495393)
       References: See also: Bug #26422857.

     * Linux: On Alpine Linux, mysql would lose its connection
       to the server if its standard output was not writable.
       Also, for mysql and mysqldump, order of result flushing
       for stdout and stderr is now deterministic. (Bug
       References: See also: Bug #17583.

     * Microsoft Windows: On Windows, with the myisam_use_mmap
       and flush system variables enabled, MyISAM did not always
       flush table files properly. (Bug #26880757)

     * JSON: JSON expressions used as arguments with the LAG()
       function were not always evaluated correctly. (Bug

     * JSON: Repeated execution of a prepared statement that
       employed JSON_ARRAY() was not handled correctly. (Bug
       References: This issue is a regression of: Bug #25867454.

     * JSON: When executing the JSON_INSERT() function, the
       check that is performed to determine whether or not a
       given insert is being made into the root element tested
       whether the length of the path was 1---that is, whether
       the path consisted of a single leg determining which
       position the inserted element has inside the root
       element. A problem occurred when there were auto-wrapping
       path legs at the beginning of the path, in which case a
       path whose length is greater than 1 might also refer to
       an element in the root, so that checking the path length
       did not reliably inform us whether the target element of
       the insert was the root or some other element.
       To fix this, the check of the path length for detection
       of the root element has been replaced with a check as to
       whether the matched element has a parent; if it has none,
       it must be the root element. (Bug #26649978)
       References: This issue is a regression of: Bug #86213,
       Bug #26022576.

     * JSON: When serializing a JSON value to its binary
       representation, it is necessary to make sure that the
       destination buffer has sufficient space to hold an
       integer or double value of the required size. Allocation
       of this buffer previously reserved only the minimum
       amount of memory needed, which made it very likely that a
       reallocation would be needed shortly thereafter. This
       could adversely affect performance, especially when
       serializing arrays with many numeric values. The
       serialization is now performed in a manner such that the
       allocation increases the size of the destination buffer
       size exponentially, which reduces the amount of the time
       spent performing this task when processing large arrays.
       (Bug #88656, Bug #27171283)

     * JSON: When a JSON document was converted to string
       representation, floating-point values that had no
       fractional part could be represented such that they
       became indistinguishable from integers. When the string
       representation of such a JSON document was passed through
       the JSON parser again, the information that the numeric
       value was originally specified as a floating-point value
       was lost.
       To rectify this problem, a fractional part is now added
       to the string representation of a floating-point value in
       a JSON document if the value has no fractional part and
       is not represented using scientific format. This makes
       the string representation of a floating-point value
       distinguishable from that of an integer, so that it
       continues to be treated as a floating-point number even
       if the string is parsed again.
       This fix also makes ST_GeomFromGeoJSON() use the same
       JSON parser as the other JSON functions rather than its
       own custom parser as had been the case since MySQL 5.7.8;
       this special handling was due to the fact that
       ST_AsGeoJSON() dropped the fractional part of negative
       zero (-0 instead of -0.0), causing the JSON parser to
       interpret -0 as integer 0, thus losing the distinction
       between positive and negative zero. Since ST_AsGeoJSON()
       now uses the standard JSON parser, it represents negative
       zero as correctly as -0.0, obviating any need for
       ST_GeomFromGeoJSON() to preserve negative zero explicitly
       on its own when parsing the output from ST_AsGeoJSON().
       (Bug #88230, Bug #27028889)
       References: See also: Bug #19504183.

     * JSON: When inserting JSON values created from the result
       of a GROUP BY query, the inserted values could sometimes
       include the concatenation of all the values previously
       inserted into that column. (Bug #87854, Bug #26867509)

     * JSON: When called using strings extracted from JSON
       documents as arguments, the LEAD() and LAG() functions
       returned the same value for every row. (Bug #87839, Bug

     * JSON: The microseconds part of the last-updated field in
       each histogram in the
       the histogram was last updated) was dropped when
       serializing the histogram into JSON and so was not
       stored. (Bug #87833, Bug #26846289)

     * JSON: When a JSON_SET() statement updated a JSON value to
       the same value using a partial update (in other words,
       when the partial update was essentially a NOOP), it was
       possible that logical diffs for this operation were
       produced, even though no binary diffs were produced. Now
       in such cases, neither logical update nor binary diffs
       are generated. (Bug #87113, Bug #26483625)

     * JSON: Following the implementation of JSON partial
       updates, the same JSON document could have different
       binary representations on the master and the slave. This
       could lead row-based replication---which uses binary
       equality to find the matching row on the slave---to fail
       if this occurred. Now the string representation of the
       JSON document is used for the comparison instead.
       Also as a result of this fix, updates can be skipped in
       more cases than previously; this is true where the binary
       representation has changed, but not the contents of the
       document. (Bug #86532, Bug #26177130)

MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql

Reply via email to