MySQL Community Server 8.0.4-rc has been released (part 2/3)
Posted by: Bjørn Munch
Date: January 23, 2018 04:04PM
Date: January 23, 2018 04:04PM
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)
Subject
Views
Written By
Posted
MySQL Community Server 8.0.4-rc has been released (part 2/3)
1750
January 23, 2018 04:04PM
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.