Skip navigation links

MySQL Forums :: Announcements :: MySQL Community Server 5.7.4 has been released (part 1/2)


Advanced Search

MySQL Community Server 5.7.4 has been released (part 1/2)
Posted by: Bjørn Munch ()
Date: March 31, 2014 10:59AM

Dear MySQL users,

MySQL Server 5.7.4 (Milestone Release) is a new version of the world's
most popular open source database. This is the fourth public milestone
release of MySQL 5.7.

[Due to length restrictions, this announcement is split into two parts.
This is part 1.]

http://dev.mysql.com/doc/mysql-development-cycle/en/development-milestone-releases.html

As with any other pre-production release, caution should be
taken when installing on production level systems or systems with
critical data.

Note that 5.7.4 includes all features in MySQL 5.6.

For information on installing MySQL 5.7.4 on new servers, please see the
MySQL installation documentation at

http://dev.mysql.com/doc/refman/5.7/en/installing.html

MySQL Server 5.7.4 is available in source and binary form for a number of
platforms from the "Development Releases" selection of our download
pages at

http://dev.mysql.com/downloads/mysql/

The platforms and package formats available for MySQL 5.7.4 are the
same as for 5.6.

MySQL Server 5.7.4 is also available from our Yum repository for
some Linux platforms, go here for details:

http://dev.mysql.com/downloads/repo/

Windows packages are now available via the new Installer for Windows
Installer or .ZIP (no-install) packages for more advanced needs. It
should be noted that the previous MSI packaging is no longer available
and the point and click configuration wizards and all MySQL products
are now available in the unified Installer for Windows:

http://dev.mysql.com/downloads/installer/

5.7.4 also comes with a web installer as an alternative to the full
installer.

The web installer doesn't come bundled with any actual products
and instead relies on download-on-demand to fetch only the
products you choose to install. This makes the initial download
much smaller but increases install time as the individual products
will need to be downloaded.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:

http://bugs.mysql.com/report.php

The following section lists the changes in MySQL 5.7.4 since the
previous milestone.

http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-4.html

Enjoy!

On behalf of the MySQL Build Team at Oracle,

- Bjorn Munch

--------------------------------------------------------------------
Changes in MySQL 5.7.4 (2014-03-31, Milestone 14)

   Note

   This is a milestone release, for use at your own risk. Significant
   development changes take place in milestone releases and you may
   encounter compatibility issues, such as data format changes that
   require attention in addition to the usual procedure of running
   mysql_upgrade. For example, you may find it necessary to dump your
   data with mysqldump before the upgrade and reload it afterward.

   Performance Schema Notes

     * The Performance Schema now instruments prepared statements
       (for both the binary and text protocols):

          + Information about prepared statements is available in the
            prepared_statements_instances table. This table enables
            inspection of prepared statements used in the server and
            provides aggregated statistics about them.

          + The performance_schema_max_prepared_statements_instances
            system variable controls the size of the table.

          + The Performance_schema_prepared_statements_lost status
            variable indicates how many prepared statements could not
            be insrumented.
       For more information, see The prepared_statements_instances
       Table
       (http://dev.mysql.com/doc/refman/5.7/en/prepared-statements-in
       stances-table.html).
       If you upgrade to this release of MySQL from an earlier
       version, you must run mysql_upgrade (and restart the server)
       to incorporate these changes into the performance_schema
       database.

   Security Notes

     * Incompatible Change: MySQL deployments installed using RPM
       packages now are secure by default. The following changes have
       been implemented as the default deployment characteristics:

          + The installation process creates only a single root
            account, 'root'@'localhost', automatically generates a
            random password for this account, and marks the password
            expired. The MySQL administrator must connect as root
            using the random password and use SET PASSWORD to select
            a new password. (The random password is found in the
            $HOME/.mysql_secret file.)

          + Installation creates no anonymous-user accounts.

          + Installation creates no test database.
       Those changes are implemented by modifying the default mode of
       operation for mysql_install_db, which is invoked automatically
       during RPM installation operations. Therefore, the changes
       also affect non-RPM installation methods for which you invoke
       mysql_install_db manually.
       Because mysql_install_db deployment now is secure by default,
       the --random-passwords option is unnecessary and has been
       removed. It has been replaced by the --skip-random-passwords
       option. You can use this option to explicitly produce a
       deployment that is not secure by default:

          + Installation creates a single root account,
            'root'@'localhost', that has no password.

          + A test database is created that is accessible by any
            user.
       Note
       mysql_install_db no longer creates anonymous-user accounts,
       even with --skip-random-passwords.
       The mysql_secure_installation program now has a --use-default
       option, which causes the program to execute noninteractively.
       It can be used for unattended install operations.

     * Incompatible Change: MySQL now enables database administrators
       to establish a policy for automatic password expiration: Any
       user who connects to the server using an account for which the
       password is past its permitted lifetime must change the
       password. The implementation has these components:

          + The default_password_lifetime system variable defines
            global password expiration policy. A value of N greater
            than zero means that passwords have a lifetime of N days.
            A value of 0 disables automatic password expiration. The
            default is 360; passwords must be changed approximately
            once per year.

          + The mysql.user table has new columns that store
            expiration policy information for individual accounts:
               o password_last_changed indicates when the password
                 was last changed. The server uses this column when
                 clients connect to determine whether the password is
                 past its lifetime and must be changed per the
                 expiration policy in effect.
               o password_lifetime indicates the account password
                 lifetime. A value of N greater than zero means that
                 the password has a lifetime of N days. 0 disables
                 automatic password expiration. NULL (the default)
                 means that the global expiration policy applies.

          + The ALTER USER statement has new options to set password
            expiration policy for individual accounts.
       If you upgrade to this release of MySQL from an earlier
       version, you must run mysql_upgrade (and restart the server)
       to incorporate the changes to the mysql.user table. For each
       account, mysql_upgrade uses the time at which it executes to
       set the password_last_changed column and sets
       password_lifetime to NULL. This causes the default global
       expiration policy to go into effect (passwords have a lifetime
       of 360 days).
       For more information, see Password Expiration Policy
       (http://dev.mysql.com/doc/refman/5.7/en/password-expiration-po
       licy.html), and ALTER USER Syntax
       (http://dev.mysql.com/doc/refman/5.7/en/alter-user.html).

   Functionality Added or Changed

     * Performance; InnoDB: InnoDB now supports multiple page_cleaner
       threads for flushing dirty pages from buffer pool instances. A
       new system variable, innodb_page_cleaners, is used to specify
       the number of page_cleaner threads. The default value of 1
       maintains the pre-MySQL 5.7.4 configuration in which there is
       only a single page_cleaner thread. This enhancement builds on
       work completed in MySQL 5.6.2, which introduced a single page
       cleaner thread to offload buffer pool flushing work from the
       InnoDB master thread.

     * Incompatible Change: The AES_ENCRYPT() and AES_DECRYPT()
       functions now permit control of the block encryption mode and
       take an optional initialization vector argument:

          + The new block_encryption_mode system variable controls
            the mode for block-based encryption algorithms. Its
            default value is aes-128-ecb, which signifies encryption
            using a key length of 128 bits and ECB mode.

          + An optional init_vector argument provides an
            initialization vector for encryption modes that require
            it:
AES_ENCRYPT(str,key_str[,init_vector])
AES_DECRYPT(crypt_str,key_str[,init_vector])

          + A random string of bytes to use for the initialization
            vector can be produced by calling the new RANDOM_BYTES()
            function.
       For more information, see Encryption and Compression Functions
       (http://dev.mysql.com/doc/refman/5.7/en/encryption-functions.h
       tml).
       These changes make statements that use AES_ENCRYPT() or
       AES_DECRYPT() unsafe for statement-based replication and they
       cannot be stored in the query cache. Queries that use
       RANDOM_BYTES() are unsafe for statement-based replication and
       cannot be stored in the query cache.

     * Incompatible Change: The deprecated
       ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE
       SQL modes now do nothing. Instead, their previous effects are
       included in the effects of strict SQL mode (STRICT_ALL_TABLES
       or STRICT_TRANS_TABLES). In other words, strict mode now means
       the same thing as the previous meaning of strict mode plus the
       ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE
       modes. This change reduces the number of SQL modes with an
       effect dependent on strict mode and makes them part of strict
       mode itself.
       To prepare for the SQL mode changes in this version of MySQL,
       it is advisable before upgrading to read SQL Mode Changes in
       MySQL 5.7
       (http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode
       -changes). That discussion provides guidelines to assess
       whether your applications will be affected by these changes.
       The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and
       NO_ZERO_IN_DATE SQL modes are still recognized so that
       statements that name them do not produce an error, but will be
       removed in a future version of MySQL. To make advance
       preparation for versions of MySQL in which these modes do not
       exist, applications should be modified to not refer to those
       mode names.

     * InnoDB: InnoDB now supports the Transportable Tablespace
       (http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_tra
       nsportable_tablespace) feature for partitioned InnoDB tables
       and individual InnoDB table partitions. This enhancement eases
       backup procedures for partitioned tables and enables copying
       of partitioned tables and individual table partitions between
       MySQL instances. For additional information, see Copying
       Tablespaces to Another Server (Transportable Tablespaces)
       (http://dev.mysql.com/doc/refman/5.7/en/tablespace-copying.htm
       l). (Bug #18121824, Bug #70196, Bug #18304194, Bug #71784)

     * InnoDB: Parameters used to identify an InnoDB pages are
       replaced by two new classes, and fold value and zip_size value
       calculations have been optimized. These changes simplify code
       by reducing the number of page identifier parameters passed to
       functions. (Bug #18073495)

     * InnoDB: The Fusion-io Non-Volatile Memory (NVM) file system on
       Linux provides atomic
       (http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ato
       mic) write capability, which makes the InnoDB doublewrite
       buffer
       (http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dou
       blewrite_buffer) redundant. For system tablespace files
       (ibdata files
       (http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ibd
       ata_file)) located on Fusion-io devices that support atomic
       writes, the InnoDB doublewrite buffer is automatically
       disabled. (Bug #18069105)

     * InnoDB: Reverse index leaf page scan has been optimized.
       btr_pcur_restore_position_func() can now perform optimistic
       restoration for reverse cursors, which reduces block->mutex
       contention on the root page, especially for concurrent reverse
       scans. (Bug #17666170)

     * InnoDB: A new system variable, innodb_log_write_ahead_size,
       allows you to configure the write-ahead block size for redo
       logs to a value that matches the operating system or file
       system cache block size in order to avoid "read-on-write" for
       redo log writes. Read-on-write occurs when redo log blocks are
       not entirely cached to the operating system or file system due
       to a mismatch between write-ahead block size for redo logs and
       operating system or file system cache block size. Avoiding
       read-on-write improves throughput stability for redo log
       writes. (Bug #17571371)

     * InnoDB: MySQL now supports rebuilding regular and partitioned
       InnoDB tables using online DDL
       (http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html
       ) (ALGORITHM=INPLACE) for the following operations:

          + OPTIMIZE TABLE

          + ALTER TABLE ... FORCE

          + ALTER TABLE ... ENGINE=INNODB (when run on an InnoDB
            table)
            Online DDL
            (http://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl
            .html) support reduces table rebuild time and permits
            concurrent DML, which helps reduce user application
            downtime. For additional information, see Overview of
            Online DDL
            (http://dev.mysql.com/doc/refman/5.7/en/innodb-create-ind
            ex-overview.html).
       (Bug #13975225)

     * InnoDB: New global configuration parameters,
       innodb_status_output and innodb_status_output_locks, allow you
       to dynamically enable and disable the standard InnoDB Monitor
       and InnoDB Lock Monitor for periodic output. Previously,
       enabling and disabling these monitors for periodic output
       required creating and dropping specially named tables
       (innodb_monitor and innodb_lock_monitor). For additional
       information, see InnoDB Monitors
       (http://dev.mysql.com/doc/refman/5.7/en/innodb-monitors.html).

     * InnoDB: The InnoDB Tablespace Monitor and InnoDB Table Monitor
       are removed in MySQL 5.7.4. For the Tablespace Monitor,
       equivalent functionality will be introduced before the GA
       release of MySQL 5.7. For the Table Monitor, equivalent
       information can be obtained from InnoDB INFORMATION_SCHEMA
       tables.

     * InnoDB: MySQL now includes a gb18030 character set that
       supports the China National Standard GB18030 character set.
       For more information about MySQL character set support, see
       Character Set Support
       (http://dev.mysql.com/doc/refman/5.7/en/charset.html).

     * Replication: The binary log dump thread has been optimized by
       removing unnecessary reallocation of the send buffer.
       Previously, memory was allocated then freed for every event
       sent to the slave, even when this was not strictly necessary.
       Following this optimization, the MySQL Server can make better
       use of hardware resources by having the dump thread employ
       adaptative memory allocation, which can also result in less
       CPU usage. (Bug #11747349, Bug #31932, Bug #11752288, Bug
       #43426, Bug #13727951)

     * Replication: Implemented separate threads for sending and
       receiving semisynchronous replication acknowledgement signals,
       so that event streams and ACK streams can be sent and received
       simultaneously. This should reduce many common delays and thus
       improve performance with semisynchronous replication in a
       number of settings.

     * Replication: It is now possible in many cases to execute
       CHANGE MASTER TO without first issuing STOP SLAVE. This
       capability is added by implementing the following changes in
       the behavior of the CHANGE MASTER TO statement, which now
       depends only on whether the slave SQL thread or slave I/O
       thread is stopped, as described here:

          + If the SQL thread is stopped, you can execute CHANGE
            MASTER TO using the RELAY_LOG_FILE, RELAY_LOG_POS, and
            MASTER_DELAY options, even if the slave I/O thread is
            running. No other options may be used with this statement
            when the I/O thread is running.

          + If the I/O thread is stopped, you can execute CHANGE
            MASTER TO using any of the options for this statement
            except RELAY_LOG_FILE, RELAY_LOG_POS, or MASTER_DELAY,
            even when the SQL thread is running. These three options
            cannot be used when the I/O thread is running.

          + Both the SQL thread and the I/O thread must be stopped
            before issuing CHANGE MASTER TO with MASTER_AUTO_POSITION
            = 1.
       If you are using statement-based replication and temporary
       tables, it is possible for a CHANGE MASTER TO statement
       following a STOP SLAVE statement to leave behind temporary
       tables on the slave. As part of this set of improvements, a
       warning is now issued whenever this occurs. You can avoid this
       in such cases by making sure that Slave_open_temp_tables is
       equal to 0 prior to executing these statements.
       For more information, see CHANGE MASTER TO Syntax
       (http://dev.mysql.com/doc/refman/5.7/en/change-master-to.html)
       , and Switching Masters During Failover
       (http://dev.mysql.com/doc/refman/5.7/en/replication-solutions-
       switch.html).

     * Performance Schema performance was improved in the following
       ways:

          + When a thread connects, reset of all per-thread
            statistics is now delayed until a statistic is actually
            collected. This lazy initialization benefits workloads
            with very short-lived sessions, for which instrumentation
            is disabled.

          + When a thread disconnects, the per-thread statistics are
            aggregated to a parent only for statistics that actually
            collected data. This optimization benefits workloads with
            very short-lived sessions, for which instrumentation is
            disabled.

          + For statement instrumentation, reset of an individual
            EVENT_NAME statistic is also now delayed until a
            statistic is actually collected. This benefits all
            workloads that contain only a few types of statements
            (SELECT, INSERT, UPDATE, DELETE, and so forth) from the
            very large set statements supported in MySQL. Only
            statements for event names actually executed are
            aggregated on disconnect.

          + The memory footprint of internal memory buffers is
            reduced, by removing some attributes reserved for future
            use, that were in fact not used. In particular,
            statistics for mutexes, rwlocks and conditions now need
            less memory.
       (Bug #18324285)

     * On Windows, NOMINMAX is set using the ADD_DEFINITIONS() CMake
       macro rather than in config.h.cmake so that it is set even
       without including my_config.h. (Bug #18192896)

     * On Solaris, mysql_config --libs now includes
       -R/path/to/library so that libraries can be found at runtime.
       (Bug #18235669)

     * CMake support for compiling MySQL with gcc on Solaris was
       improved. Binary distributions for Solaris now are built using
       gcc rather than Sun Studio, to enable compilation of code not
       handled by Sun Studio. The client programs and the client
       libraries except the embedded library are still built using
       Sun Studio.
       A consequence of this change is that on Solaris, mysql_config
       no longer provides arguments for linking with the embedded
       library, since this is now built using gcc instead of Sun
       Studio. To get linking arguments for the embedded library, use
       the alternative script mysql_server_config instead. (Bug
       #18146422, Bug #17826757)

     * The CHECK_FUNCTION_REPLACEMENT() CMake macro was removed from
       Windows.cmake and replacement functions are set explicitly
       instead since the result of the check was already hard coded
       in WindowsCache.cmake. (Bug #18116661)

     * MySQL now compiles using Clang 3.4. (Bug #18047020)

     * In MySQL 5.7.1, the MySQL test suite mysql-test-run.pl program
       was modified to start the server with InnoDB rather than
       MyISAM as the default storage engine. All tests in the MySQL
       test suite were modified to include a force_default_myisam.inc
       file. This had to be done because most legacy test results
       were recorded with the MyISAM engine and failed with a result
       difference if run with InnoDB. A project is underway to
       migrate these tests and remove force_default_myisam.inc for
       tests that do not need MyISAM. In 5.7.4, the rpl and binlog
       suites and parts of the main suite were migrated. (Bug
       #17902011)

     * Performance Schema instrumentation was added to capture GTIDs
       for transaction events. (Bug #17799147)

     * Performance Schema overhead was reduced for the pfs_lock
       implementation and the uses of atomic operations in general.
       (Bug #17766582)

     * CMake now aborts the configuration process on Windows if a
       Visual Studio version earlier than 2010 is used. (Bug
       #17730320)

     * A new CMake option, WITH_MSAN, permits enabling
       MemorySanitizer for compilers that support it. (Bug #17632319)

     * Previously, ALTER TABLE in MySQL 5.6 could alter a table such
       that the result had temporal columns in both 5.5 and 5.6
       format. Now ALTER TABLE upgrades old temporal columns to 5.6
       format for ADD COLUMN, CHANGE COLUMN, MODIFY COLUMN, ADD
       INDEX, and FORCE operations. This conversion cannot be done
       using the INPLACE algorithm, so specifying ALGORITHM=INPLACE
       in these cases results in an error. (Bug #17246318)

     * Overhead was reduced for filesort comparison operations. (Bug
       #14635144)

     * Overhead was reduced for metadata lock acquisition for DML
       statements. (Bug #58627, Bug #11765641)

     * CMake now supports a -DTMPDIR=dir_name option to specify the
       default tmpdir value. If unspecified, the value defaults to
       P_tmpdir in <stdio.h>. Thanks to Honza Horak for the patch.
       (Bug #68338, Bug #16316074)

     * Based on community feedback, the default value of 10 for the
       eq_range_index_dive_limit system variable has proven to be too
       low. The default has been raised to 200. (Bug #70586, Bug
       #17587952)

     * Code instrumented with Valgrind did not preallocate memory in
       alloc_root(), to help find bugs. This behavior is now also
       enabled if ASAN (address sanitizer) is used. (Bug #44582, Bug
       #11753184)

     * mysql_install_db provides a more informative diagnostic
       message when required Perl modules are missing. (Bug #69844,
       Bug #18187451)

     * MySQL now supports server-side timeouts for execution of
       SELECT statements:

          + SELECT supports a MAX_STATEMENT_TIME option to specify a
            timeout for individual queries. For example:
SELECT MAX_STATEMENT_TIME = 5000 id, name FROM my_table WHERE ...

          + The max_statement_time system variable specifies the
            timeout value for SELECT statements executed within the
            session that include no MAX_STATEMENT_TIME option. If the
            value is 0, timeouts are not enabled.

          + The Max_statement_time_exceeded, Max_statement_time_set,
            and Max_statement_time_set_failed status variables
            provide information about SELECT statements affected by
            timeouts.
       Timeout values are in milliseconds.
       For more information, see SELECT Syntax
       (http://dev.mysql.com/doc/refman/5.7/en/select.html), and
       Server System Variables
       (http://dev.mysql.com/doc/refman/5.7/en/server-system-variable
       s.html).
       Thanks to Davi Arnaut for the patch on which this feature is
       based. (Bug #68252, Bug #16271666)

     * The metadata locking subsystem implementation now uses
       lock-free hashing rather than a hash protected by a mutex. An
       implication of this change is that the
       metadata_locks_cache_size and metadata_locks_hash_instances
       system variables no longer have any effect, so they are
       deprecated and will be removed in a future MySQL release.

     * The deprecated IGNORE clause for ALTER TABLE has been removed
       and its use produces an error.

     * The metadata locking subsystem now uses a lock-free algorithm
       for acquiring and releasing locks typical for DML statements.
       This gives better performance/scalability on multi-core
       machines in workloads involving lots of small read-only
       transactions.

     * To make it possible to change connections in a load-balanced
       environment, it is necessary to detect in the response packet
       whether there is session state to take into consideration when
       deciding whether a switch can be made. For this purpose,
       session state consists of these values:

          + The default schema (database)

          + Session-specific values for system variables

          + User-defined variables

          + Temporary tables

          + Prepared statements
       The OK response packet of the MySQL client/server protocol now
       includes tracker information so that session state changes can
       be detected. The tracker mechanism provides a means for MySQL
       Connectors, Fabric, and client applications to determine
       whether any session context is available to ensure session
       migration from one server to another. The user interface to
       control the tracker and retrieve state-change information from
       it has the following components, which enable implementation
       of state-change tracking on the client side:

          + Clients can request notification when there is a change
            to any of the session state-related values just listed,
            in the form of a flag that is set in the OK packet
            received from the server after the change occurs. To
            control notification, enable or disable the
            session_track_state_change system variable. This variable
            is disabled by default.

          + Clients can request notification of changed values for
            certain specific types of session state information:
               o The default schema name. To control notification,
                 enable or disable the session_track_schema system
                 variable. This variable is enabled by default.
               o The session values of system variables. Notification
                 occurs for the system variables named by the
                 session_track_system_variables system variable. By
                 default, notification is enabled for time_zone,
                 autocommit, character_set_client,
                 character_set_results, and character_set_connection.
                 (The latter three variables are those affected by
                 SET NAMES.)

          + To enable applications to extract the state-change
            information returned in the OK packet by the server, the
            MySQL C API includes a pair of functions:
               o mysql_session_track_get_first() fetches the first
                 state-change information received from the server.
               o mysql_session_track_get_next() fetches any remaining
                 state-change information received from the server.
                 Following a successful call to
                 mysql_session_track_get_first(), call this function
                 repeatedly as long as it returns success.

          + The mysqltest program has enable_session_track_info and
            disable_session_track_info commands to enable and disable
            tracking of session state-change information.
       For more information, see Server System Variables
       (http://dev.mysql.com/doc/refman/5.7/en/server-system-variable
       s.html) and mysql_session_track_get_first()
       (http://dev.mysql.com/doc/refman/5.7/en/mysql-session-track-ge
       t-first.html). For information about the structure of the OK
       packet itself, see OK_Packet
       (http://dev.mysql.com/doc/internals/en/packet-OK_Packet.html).

     * MySQL Yum Repository: mysqlbug
       (http://dev.mysql.com/doc/refman/5.7/en/mysqlbug.html), an
       obsolete program for generating bug reports, has been removed
       from the RPM packages delivered by the MySQL Yum Repository
       for installing the MySQL Server on EL5, EL6, and EL7-based
       platforms.

   Bugs Fixed

     * Incompatible Change: Old clients (older than MySQL 5.5.7)
       failed to parse authentication data correctly if the server
       was started with the
       --default-authentication-plugin=sha256_password option.
       Note
       As a result of this bug fix, MySQL 5.6.16 clients cannot
       connect to a 5.6.17 server using an account that authenticates
       with the sha256_password plugin. Similarly, MySQL 5.7.3
       clients cannot connect to a 5.7.4 server using an account that
       authenticates with the sha256_password plugin.
       (Bug #17495562)

     * Important Change; InnoDB; Partitioning: The FLUSH TABLES
       statement's FOR EXPORT option is now supported for partitioned
       InnoDB tables. (Bug #16943907)

     * InnoDB; Replication: Using the InnoDB memcached plugin (see
       InnoDB Integration with memcached
       (http://dev.mysql.com/doc/refman/5.7/en/innodb-memcached.html)
       ) with innodb_api_enable_binlog set to 1 caused the server to
       leak memory. (Bug #70757, Bug #17675622)

     * InnoDB: trx_undo_truncate_start would write to the redo log
       for temporary undo log segments, resulting in a purge thread
       assertion. (Bug #18252937)

     * InnoDB: A !sync_check_iterate(check) assertion occurred in
       fts_create_doc_id() during an INSERT operation. (Bug
       #18253210)

     * InnoDB: The GCC 4.4 Compiler would emit a bogus warnings about
       InnoDB parsing functions, indicating that output is
       uninitialized. (Bug #18192536)

     * InnoDB: log_mutex_exit should be called before
       log_buffer_extend when the log buffer mutex is held. (Bug
       #18202904)

     * InnoDB: InnoDB would write to the redo log for some operations
       on temporary tablespaces. (Bug #18226934)

     * InnoDB: Doublewrite buffer error messages referenced page
       numbers in an inconsistent manner. (Bug #18242594)

     * InnoDB: The truncate_t::drop_indexes and
       truncate_t::create_indexes methods would disable redo logging
       when modifying the system tablespace. (Bug #18236000)

     * InnoDB: Unused parameters and variables along with disabled
       functionality has been removed from redo log code. This patch
       also includes redo log code improvements including test
       enablement, addition of Valgrind instrumentation, and minor
       code refactoring. (Bug #18251675)

     * InnoDB: An invalid memmove in fts_query_fetch_document would
       cause a serious error. (Bug #18229433)

     * InnoDB: For full-text queries, a failure to check that
       num_token is less than max_proximity_item could result in an
       assertion. (Bug #18233051)

     * InnoDB: InnoDB would perform unnecessary redo log writes and
       flushing for temporary tablespaces. (Bug #18236692)

     * InnoDB: The user defined type, xid_t, was defined multiple
       times. (Bug #18251254)

     * InnoDB: To simplify code and reduce memory usage, InnoDB redo
       log scan records for file-level operations, previously stored
       in a hash table, are now processed immediately. (Bug
       #18180875)

     * InnoDB: The loader in some Solaris versions would refuse to
       start a GCC-compiled binary (such as the mysqld binary) that
       uses the PAUSE assembler instruction. (Bug #18122171)

     * InnoDB: Temporary tablespace file size did not match the file
       size specified by --innodb-temp-data-file-path due to an error
       in file size allocation logic. (Bug #18141070)

     * InnoDB: innodb_ft_result_cache_limit now has a hardcoded
       maximum value of 4294967295 bytes or (2**32 -1). The maximum
       value was previously defined as the maximum value of ulong.
       (Bug #18180057, Bug #71554)

     * InnoDB: InnoDB would fail to restore a corrupt first page of a
       system tablespace data file from the doublewrite buffer,
       resulting in a startup failure. (Bug #18144349, Bug #18058884)

     * InnoDB: An UPDATE resulted in a memory access error in
       lock_rec_other_trx_holds_expl. The transaction list
       (trx_sys->rw_trx_list) was traversed without acquiring the
       transaction subsystem mutex (trx_sys->mutex). (Bug #18161853)

     * InnoDB: TRUNCATE TABLE on Windows would report multiple
       'chsize' returned OS error 71 errors. (Bug #18176071, Bug
       #71173)

     * InnoDB: A regression introduced by Bug #14329288 would result
       in a performance degradation when a compressed table does not
       fit into memory. (Bug #18124788, Bug #71436)

     * InnoDB: In the case of a corrupted clustered index on a
       temporary table, the server would crash on an INSERT instead
       of returning an error. In the case of a corrupted clustered
       index on a normal table, an error was not returned and the
       INSERT would succeed. (Bug #18064548)

     * InnoDB: Specifying an alternate directory for InnoDB tables
       using datadir and then moving .ibd files
       (http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ibd
       _file) to the default MySQL data directory would result in a
       serious error when attempting a DROP TABLE operation. (Bug
       #18063570)

     * InnoDB: The UNIV_LOG_DEBUG debug flag, which is no longer
       fully functional, has been removed. (Bug #18080537)

     * InnoDB: A compilation error (unable to find string literal
       operator) was returned when building in c++11 mode. (Bug
       #18082139)

     * InnoDB: INFORMATION_SCHEMA.INNODB_TRX contained a bogus
       transaction ID that did not match transaction ID values
       printed elsewhere. The method used to retrieve transaction IDs
       was inconsistent. (Bug #18111007)

     * InnoDB: The maximum value for innodb_thread_sleep_delay is now
       1000000 microseconds. The previous maximum value (4294967295
       microseconds on 32-bit and 18446744073709551615 microseconds
       on 64-bit) was unnecessarily large. Because the maximum value
       of innodb_thread_sleep_delay is limited by the value set for
       innodb_adaptive_max_sleep_delay (when set to a non-zero
       value), the maximum value for innodb_thread_sleep_delay is now
       the same as the maximum value for
       innodb_adaptive_max_sleep_delay. (Bug #18117322)

     * InnoDB: The fil_node_create function would perform an
       unnecessary hash table lookup. (Bug #18116588)

     * InnoDB: When starting the server, unnecessary "checking space"
       log messages would be printed when processing the doublewrite
       buffer
       (http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dou
       blewrite_buffer). (Bug #18101380)

     * InnoDB: A full-text tokenizer thread would terminate with an
       incorrect error message. (Bug #18021306)

     * InnoDB: Attempting to uninstall the InnoDB memcached plugin
       while the InnoDB memcached plugin is still initializing would
       kill the InnoDB memcached daemon thread. Uninstall should wait
       until initialization is complete. (Bug #18038948)

     * InnoDB: In debug builds, creating a unique index on a binary
       column, with input data containing duplicate keys, would cause
       an assertion. (Bug #18010711)

     * InnoDB: Logging functions were not used consistently. The bug
       fix replaces occurrences of fprintf(stderr, message) and
       fputs() with ib_logf(). Also, because ib_logf() emits a
       timestamp with each message, the bug fix removes unnecessary
       occurrences of ut_print_timestamp(). (Bug #17935793, Bug
       #17534737)

     * InnoDB: A boolean mode full-text search query would result in
       a memory access violation during parsing. (Bug #17978763)

     * InnoDB: The srv_monitor_thread would crash in the
       lock_print_info_summary() function due to a race condition
       between the srv_monitor_thread and purge coordinator thread.
       (Bug #17980590, Bug #70430)

     * InnoDB: On Windows, a regression introduced in 5.7.3 would
       allow log writes during sync operations, which should not be
       allowed due to an issue in some Windows environments. (Bug
       #17824101)

     * InnoDB: Due to a parser error, full-text search queries that
       include a sub-expression could return the wrong result. (Bug
       #17840768)

     * InnoDB: The innochecksum tool did not use a Windows-specific
       API to retrieve file size information, which resulted in an
       incorrect error message (Error: ibdata1 cannot be found) when
       the MySQL 5.6 innochecksum 2GB file size limit was exceeded.
       innochecksum now provides support for files larger than 2GB in
       both MySQL 5.6 and MySQL 5.7. (Bug #17810862, Bug #70936)

     * InnoDB: Due to a regression introduced by the fix for
       Bug#17371537, memory was not allocated for the default
       memcached engine when using the default memcached engine as
       the backstore for data instead of InnoDB. (Bug #17800829)

     * InnoDB: If a crash occurred while temporary tables are active,
       InnoDB would report an invalid error message on restart
       indicating that a temporary table does not exist in the InnoDB
       internal data dictionary. (Bug #17779729)

     * InnoDB: A page allocation for an undo log due would fail with
       a "table is full" error message instead of an "undo log is
       full" error message. (Bug #17779822)

     * InnoDB: ut_free could be called more than once in succession.
       (Bug #17763472)

     * InnoDB: An index tree modification could result in a deadlock.
       (Bug #17754767)

     * InnoDB: Manipulating a table after discarding its tablespace
       using ALTER TABLE ... DISCARD TABLESPACE could result in a
       serious error. (Bug #17700280)

     * InnoDB: A race condition in DebugPolicy::enter() would cause a
       segmentation fault in sync_array_cell_print. (Bug #17713784)

     * InnoDB: Persistent optimizer statistics would cause stalls due
       to latch contention. (Bug #17699331, Bug #70768)

     * InnoDB: MATCH() ... AGAINST queries that use a long string as
       an argument for AGAINST() could result in an error when run on
       an InnoDB table with a full-text search index. (Bug #17640261)

     * InnoDB: An InnoDB full-text search failure would occur due to
       an "unended" token. The string and string length should be
       passed for string comparison. (Bug #17659310)

     * InnoDB: Databases names beginning with a digit or special
       character would cause a full-text search (FTS) parser error.
       (Bug #17607687)
       References: See also Bug #17607956.

     * InnoDB: For debug builds, the table rebuilding variant of
       online ALTER TABLE, when run on tables with BLOB columns,
       would cause an assertion in the row_log_table_apply_update
       function. For normal builds, a DB_PRODUCTION error would be
       returned. (Bug #17661919)

     * InnoDB: Under certain conditions, a regression introduced by
       the fix for Bug #11758237 would cause an assertion error when
       INSERT ... ON DUPLICATE KEY UPDATE or REPLACE statements
       encounter a DB_DUPLICATE_KEY error. (Bug #17604730)

     * InnoDB: In debug builds, a merge insert buffer during a page
       read would cause a memory access violation. (Bug #17561188)

     * InnoDB: The patch for Bug #16852278, which simplifies and
       optimizes comparison functions in InnoDB, caused a query
       performance regression. (Bug #17543588)

     * InnoDB: Truncating a memcached InnoDB table while memcached is
       performing DML operations would result in a serious error.
       (Bug #17468031)

     * InnoDB: In sync0rw.ic, rw_lock_x_lock_func_nowait would
       needlessly call os_thread_get_curr_id. (Bug #17509710, Bug
       #70417)

     * InnoDB: Attempting to rename a table to a missing database
       would result in a serious error. (Bug #17447500)

     * InnoDB: If a tablespace data file path is updated in a .isl
       file and then a crash recovery is performed, the updated
       tablespace data file path is read from the .isl file but the
       SYS_DATAFILES table would not be not updated. The
       SYS_DATAFILES table is now updated with the new data file path
       after crash recovery. (Bug #17448389)

     * InnoDB: The server could fail to restart if a crash occurred
       immediately following a RENAME TABLE in an ALTER TABLE, RENAME
       TABLE sequence. (Bug #17463290)

     * InnoDB: If the first page (page 0) of file-per-table
       tablespace data file was corrupt, recovery would be halted
       even though the doublewrite buffer contained a clean copy of
       the page. (Bug #17335427, Bug #70087)

     * InnoDB: The InnoDB memcached Readme file
       (README-innodb_memcached) incorrectly stated that libevent
       1.6.0 is linked statically into daemon memcached. The bundled
       version of libevent is 1.4.12, not 1.6.0. (Bug #17324419, Bug
       #70034)

     * InnoDB: Attempting to reset a replication slave while
       innodb_force_recovery is greater than 0 would return a cryptic
       error message: ERROR(1030) HY000: Got error -1 from storage
       engine. The error message has been changed to: ERROR HY000:
       Operation not allowed when innodb_force_recovery > 0.
       Replication options such as --relay-log-info-repository=TABLE
       and --master-info-repository=TABLE store information in tables
       in InnoDB. When innodb_force_recovery is greater than 0,
       replication tables cannot be updated which may cause
       replication administration commands to fail. (Bug #17287443,
       Bug #69907)

     * InnoDB: When creating a table there are a minimum of three
       separate inserts on the mysql.innodb_index_stats table. To
       improve CREATE TABLE performance, there is now a single COMMIT
       operation instead of one for each insert. (Bug #17323202, Bug
       #70063)

     * InnoDB: The server would halt with an assertion in
       lock_rec_has_to_wait_in_queue(lock) due to a locking-related
       issue and a transaction being prematurely removed from
       trx_sys->rw_trx_set. (Bug #17320977)

     * InnoDB: The ALTER TABLE INPLACE algorithm would fail to
       decrease the auto-increment value. (Bug #17250787, Bug #69882)

     * InnoDB: Comments in btr0cur.cc incorrectly stated that
       btr_cur_pessimistic_update() and btr_cur_optimistic_update()
       would accept a NULL value. (Bug #17231743, Bug #69847)

     * InnoDB: dict_table_schema_check would call dtype_sql_name
       needlessly. (Bug #17193801, Bug #69802)

     * InnoDB: The function os_file_get_status would not work with
       raw devices. (Bug #17023438, Bug #69424)

     * InnoDB: fil_check_first_page() failed to check if
       fsp_flags_get_zip_size() returned a valid value, which
       resulted in a segmentation fault when starting mysqld. (Bug
       #17033182)

     * InnoDB: The lock_rec_other_has_expl_req function in
       lock0lock.cc would perform unnecessary work. (Bug #17016214,
       Bug #69576)

     * InnoDB: Valgrind would report uninitialized values while
       running a rollback debug test. The Valgrind warnings should
       only appear in Valgrind-instrumented builds. (Bug #16969876)

     * InnoDB: During crash recovery, an incorrect transaction active
       time would result in rolling back an uncommitted transaction.
       (Bug #16936961, Bug #69438)

     * InnoDB: Heap block debugging information (file_name, lineno),
       used for logging diagnostics, would appear in release builds.
       This information should only appear in debug builds. (Bug
       #16924719, Bug #69422)

     * InnoDB: Renaming a column while also adding or dropping
       columns in the same ALTER TABLE operation would cause an
       error. (Bug #16864981)

     * InnoDB: An online ALTER TABLE operation would consume more
       memory than expected. During an online ALTER TABLE operation,
       an online log buffer containing a head and tail buffer is
       created for each index that is created or rebuilt. The tail
       buffer is the writer context and is only required for
       concurrent write operations on an index while the ALTER TABLE
       operation is in progress. The head buffer is the reader
       context and is only required during the log apply phase. To
       reduce memory consumption, the tail buffer is now allocated
       when the first DML statement is run on the index, and the head
       buffer is only allocated in the log apply phase and freed
       afterwards. (Bug #16868967, Bug #69325, Bug #17911720)
[... continued ...]

Options: ReplyQuote


Subject Views Written By Posted
MySQL Community Server 5.7.4 has been released (part 1/2) 1588 Bjørn Munch 03/31/2014 10:59AM


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.