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
0.
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
#27004729)
* 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
considerations:
+ 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
#27151163)
* 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
#26995534)
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
#26950659)
* 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
#26834496)
* 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
entry in INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO. The
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
#26761960)
* 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
#87619)
* 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
rollback.
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
#26678883)
* 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
#26640776)
* 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
#26535746)
* 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
#86589)
* 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
#85925)
* 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
#82213)
* 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
#26802395)
* 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
#26770576)
* 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
#26748533)
* 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
#86224)
* 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
#86063)
* 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
#25694140)
* 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
group_replication_enforce_update_everywhere_checks=ON,
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
#27169809)
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
#26740557)
* JSON: Repeated execution of a prepared statement that
employed JSON_ARRAY() was not handled correctly. (Bug
#26704312)
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
#26848089)
* JSON: The microseconds part of the last-updated field in
each histogram in the
INFORMATION_SCHEMA.COLUMN_STATISTICS table (showing when
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