MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Bjorn Munch Date:March 10 2015 5:35pm
Subject:MySQL Community Server 5.7.6 has been released (part 1/3)
View as plain text  
Dear MySQL users,

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

[Due to size limitations on email/forum and the sheer number of changes
since 5.7.5, this announcement had to be split into three parts. This
is part 1.]

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.6-m16 includes all features in MySQL 5.6.

For information on installing MySQL 5.7.6-m16 on new servers, please see
the MySQL installation documentation at

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

MySQL Server 5.7.6-m16 is also available from our repository for Linux
platforms, go here for details:

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:

5.7.6-m16 also comes with a web installer as an alternative to the full

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.:

The following section lists the changes in MySQL 5.7.6-m16 since the
previous milestone.


- Bjorn Munch
  MySQL Release Engineering

Changes in MySQL 5.7.6 (2015-03-09, Milestone 16)


   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.

   Account Management Notes

     * Incompatible Change: The CREATE USER and ALTER USER
       statements have gained user-management capabilities.
       Together, they now can be used to fully establish or
       modify authentication, SSL, and resource-limit
       properties, as well as manage password expiration and
       account locking and unlocking. For example, ALTER USER
       can assign passwords, and it can modify the
       authentication plugin for users with no need for direct
       manipulation of the mysql.user table. For details, see
       CREATE USER Syntax
       , and ALTER USER Syntax
       Account locking control is a new feature that permits
       administrators to completely disable an account from
       being used to connect to the server. Account locking
       state is recorded in the account_locked column of the
       mysql.user table. See User Account Locking
       A new statement, SHOW CREATE USER, shows the CREATE USER
       statement that creates the named user. The accompanying
       Com_show_create_user status variable indicates how many
       times the statement has been executed.
       A new system variable,
       log_backward_compatible_user_definitions, if enabled,
       causes the server to log CREATE USER, ALTER USER, and
       GRANT statements in backward-compatible (pre-5.7.6)
       fashion. Enabling this variable promotes compatibility
       for cross-version replication.
       The authentication_string column in the mysql.user table
       now stores credential information for all accounts. The
       Password column, previously used to store password hash
       values for accounts authenticated with the
       mysql_native_password and mysql_old_password plugins, is
       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 database.
       mysql_upgrade moves Password column values to the
       authentication_string column and removes the Password
       column. For nonupgraded installations that have no
       account_locked column, the server treats all accounts as
       unlocked, and attempts to lock or unlock and account
       produce an error.
       The preceding changes make the following features
       obsolete. They are now deprecated and support for them
       will be removed in a future MySQL release:

          + Using GRANT to create users. Instead, use CREATE
            USER. Following this practice makes the
            NO_AUTO_CREATE_USER SQL mode immaterial for GRANT
            statements, so it too is deprecated.

          + Using GRANT to modify account properties other than
            privilege assignments. This includes authentication,
            SSL, and resource-limit properties. Instead,
            establish such properties at account-creation time
            with CREATE USER or modify them afterward with ALTER

          + IDENTIFIED BY PASSWORD 'hash_string' syntax for
            CREATE USER and GRANT. Instead, use IDENTIFIED BY
            auth_plugin AS 'hash_string' for CREATE USER and
            ALTER USER, where the 'hash_string' value is in a
            format compatible with the named plugin.

          + The SET PASSWORD statement and the PASSWORD()
            function. Instead, use ALTER USER to change account
            passwords, and avoid using PASSWORD() in any
            The changes in this release result in a semantic
            incompatibility for one SET PASSWORD syntax:
SET PASSWORD ... = 'literal string';

            Previously, SET PASSWORD interpreted the string as a
            password hash value to be stored directly. Now, SET
            PASSWORD interprets the string as a plaintext string
            and hashes it appropriately for the account
            authentication plugin before storing it.
            Any application that uses PASSWORD() to create hash
            values (a practice that has been discouraged for
            some time) should be modified to use a different
            hash-generation method. For suggestions, see the
            description of PASSWORD() in Encryption and
            Compression Functions

          + The old_passwords system variable. Account
            authentication plugins can no longer be left
            unspecified in the mysql.user table, so any
            statement that assigns a password from a plaintext
            string can unambiguously determine the hashing
            method to use on the string before storing it in the
            mysql.user table. This renders old_passwords
       It is a known bug in this release that the following SET
       PASSWORD syntax produces an error:
SET PASSWORD ... = PASSWORD('auth_string');

       That syntax was to be deprecated, not removed. It will be
       restored in the next release, but generate a warning due
       to its deprecated status. These alternatives are
       available, the first of which is the preferred form:
ALTER USER ... IDENTIFIED BY 'auth_string';
SET PASSWORD ... = 'auth_string';

       The change in mysql.user table structure has
       compatibility implications for upgrading and downgrading:

          + You cannot use mysqldump to dump the user table from
            a version of MySQL older than 5.7.6 and reload the
            dump file into MySQL 5.7.6 or later. Instead,
            perform a binary (in-place) upgrade to MySQL 5.7.6
            or later and run mysql_upgrade to migrate the
            Password column contents to the
            authentication_string column.

          + Because the Password column is gone in 5.7.6 and up,
            downgrading to a version older than 5.7.6 requires a
            special procedure. See Downgrading to MySQL 5.6

   Generated Columns

     * MySQL now supports the specification of generated columns
       in CREATE TABLE and ALTER TABLE statements. Values of a
       generated column are computed from an expression
       specified at column creation time. Generated columns can
       be virtual (computed "on the fly" when rows are read) or
       stored (computed when rows are inserted or updated). The
       INFORMATION_SCHEMA.COLUMNS table shows information about
       generated columns.
       Uses for generated columns include simplifing queries
       when applications select from a table using a complex
       expression, simulating functional indexes, or
       substituting for views. For more information, see
       Generated Columns

   Installation Notes

     * Previously, for a new MySQL installation on Unix and
       Unix-like systems, initialization of the data directory
       (including the tables in the mysql system database) was
       done using mysql_install_db. On Windows, MySQL
       distributions included a data directory with prebuilt
       tables in the mysql database.
       mysql_install_db functionality now has been integrated
       into the MySQL server, mysqld. To use this capability to
       initialize a MySQL installation, if you previously
       invoked mysql_install_db manually, invoke mysqld with the
       --initialize or --initialize-insecure option, depending
       on whether you want the server to generate a random
       password for the initial 'root'@'localhost' account.
       As a result of this change, mysql_install_db is
       deprecated, as is the special --bootstrap option that
       mysql_install_db passes to mysqld. These will be removed
       in a future MySQL release. Also, the $HOME/.mysql_secret
       file written by mysql_install_db is no longer needed. If
       it is present on your system, you can remove it.
       Initializing a MySQL installation using mysqld works on
       all platforms, including Windows. In particular, it is
       possible to initialize a Windows installation without the
       set of prebuilt tables for the mysql database. (However,
       it is unnecessary to do so for this release because
       Windows distributions still include the pre-built
       For more information, see Initializing the Data Directory
       Using mysqld

   Optimizer Notes

     * The optimizer now minimizes differences in handling of
       views and subqueries in the FROM clause. One effect of
       this is that subqueries in the FROM clause, previously
       always materialized to an internal temporary table, now
       may be merged into the outer query. This can improve
       performance. Avoiding materialization also can enable the
       optimizer to push down conditions to the subquery and
       produce a more efficient execution plan. For an example,
       see Optimizing Subqueries with Subquery Materialization
       References: See also Bug #20073366, Bug #59203, Bug

   Packaging Notes

     * Packaging scripts such as those included in RPM or Debian
       packages have been modified per the principle that files
       installed from MySQL distributions should have the most
       restrictive permissions possible. In the following
       description, assume that the account used to administer
       MySQL has owner (user) = mysql, group = mysql.

          + Installers that create the mysql account do so with
            a shell of /bin/false to prevent direct login to the

          + The data directory and its contents are owned by and
            accessible only to owner/group mysql/mysql, with
            permissions of 750 for directories, 755 for
            executable files, 640 for other files.

          + Others files (including executables and libraries)
            have owner/group of root/root, with these
               o Executables: 755
               o Man pages, character set files, header files,
                 test suite files: 644
               o Library files: Conventions appropriate for the
                 host system
       Packaging scripts that perform the preceding actions for
       installation also perform them for upgrades, with the
       exceptions that if the mysql account exists, it is left
       unchanged, and if the data directory exists, its
       permissions and ownership are left unchanged.

   Performance Schema Notes

     * The Performance Schema now incorporates these changes:

          + Previously, the Performance Schema enabled
            instrumentation for new foreground threads if there
            was a row in the setup_actors table that matched the
            thread user and host. Now, the setup_actors table
            has an ENABLED column that indicates whether or not
            to enable instrumentation for matching foreground
            threads. This permits instrumentation for matching
            threads to be disabled explicitly. For more
            information, see Pre-Filtering by Thread

          + Two previously hardcoded limits on SQL statement
            handling are now configurable:
               o The maximum number of bytes from SQL statements
                 to display in the SQL_TEXT column of statement
                 event tables, such as
               o The number of bytes used for computing
                 statement digests. Digests appear in the
                 DIGEST_TEXT and DIGEST columns of statement
                 event tables.
            Previously, both values were fixed at 1024. It is
            now possible to change them at server startup using
            the performance_schema_max_sql_text_length and
            max_digest_length system variables. (The name
            max_digest_length does not begin with
            performance_schema_ because statement digesting is
            now done at the SQL level even if the Performance
            Schema is disabled and is available to other aspects
            of server operation that could benefit from it. For
            example, query rewrite plugins now make use of
            statement digests, even if the Performance Schema is
            The defaults remain at 1024, but the values can be
            reduced to use less memory or increased to permit
            longer statements to be distinguished for display
            and digesting purposes. Each variable has a range
            from 0 to 1024 x 1024.
            Any bytes in excess of
            performance_schema_max_sql_text_length are discarded
            and do not appear in the SQL_TEXT column. Statements
            differing only after that many initial bytes are
            indistinguishable in this column.
            Any bytes in excess of max_digest_length during
            digest computation do not factor into digest values.
            Statements differing only after that many bytes of
            parsed statement tokens produce the same digest and
            are aggregated for digest statistics.
            For applications that generate very long statements
            that differ only at the end, the ability to change
            max_digest_length variables enables computation of
            digests that distinguish statements that previously
            were aggregated to the same digest. Conversely,
            administrators can devote less server memory to
            digest storage by reducing the values of this
            variable. Administrators should keep in mind that
            larger values result in correspondingly increased
            memory requirements, particularly for workloads that
            involve large numbers of simultaneous sessions.
            (max_digest_length bytes are allocated per session.)
            For more information, see Performance Schema
            Statement Digests
       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

     * The secure_file_priv system variable is used to limit the
       effect of data import and export operations. The
       following changes have been made to how the server
       handles this variable:

          + The server checks the value of secure_file_priv at
            startup and writes a warning to the error log if the
            value is insecure. The setting is considered
            insecure if secure_file_priv has an empty value, or
            the value is the data directory or a subdirectory of
            it, or a directory that is accessible by all users.
            If secure_file_priv is set to a nonexistent path,
            the server writes an error message to the error log
            and exits.

          + secure_file_priv can be set to NULL to disable all
            import and export operations.

          + Previously, the secure_file_priv system variable was
            empty by default. Now the default value is platform
            specific and depends on the value of the
            INSTALL_LAYOUT CMake option, as shown in the
            following table.

 INSTALL_LAYOUT Value          Default secure_file_priv Value
 STANDALONE, WIN      empty
 DEB, RPM, SLES, SVR4 /var/lib/mysql-files
 Otherwise            mysql-files under the CMAKE_INSTALL_PREFIX value

          + To specify the default secure_file_priv value
            explicitly if you are building from source, use the
            new INSTALL_SECURE_FILE_PRIVPATH CMake option.
       References: See also Bug #18140348.

     * MySQL Server from Community Edition distributions now
       tries to deploy with SSL support enabled automatically if
       no SSL options are specified explicitly and it finds any
       of the ca.pem, server-cert.pem, and server-key.pem files
       in the data directory. In this case, clients can use a
       secure connection merely by specifying --ssl on the
       command line.
       To make it easier to produce the files required to
       support secure connections (for both SSL and RSA), MySQL
       distributions now include the mysql_ssl_rsa_setup
       utility. This utiliy uses the openssl command, so its use
       is contingent on having OpenSSL installed on your
       machine. When invoked, mysql_ssl_rsa_setup checks the
       data directory for SSL/RSA files and uses openssl to
       create them if they are missing. For more information,
       see mysql_ssl_rsa_setup --- Create SSL/RSA Files
       If the server automatically uses SSL files at startup, it
       writes a message to the error log. If the server finds
       that the CA certificate is self-signed, it writes a
       warning to the error log. (The certificate will be
       self-signed if created by mysql_ssl_rsa_setup.)

   Spatial Data Support

     * Spatial functions now allocate memory in larger chunks to
       reduce number of allocation calls and reduce overhead.
       (Bug #20073459)

     * A new set of spatial convenience functions is available:

          + ST_Distance_Sphere(): Returns the mimimum distance
            between two geometries.

          + ST_IsValid(): Checks whether a geometry is valid.

          + ST_MakeEnvelope(): Returns the rectangle that forms
            the envelope around two points.

          + ST_Simplify(): Returns a simplified geometry.

          + ST_Validate(): Returns a validated geometry, or NULL
            if it is invalid.
       For details, see Spatial Convenience Functions

     * GIS code now uses Boost.Geometry.Rtree to improve
       handling of geometry collection arguments in binary GIS
       functions. The minimum bounding rectangles (MBRs) of
       geometry collection components are used to set up an
       rtree index, which is used to search for possible
       matching components using each MBR of the components of
       the other geometry collection. The results from the rtree
       index search are provided to precise computation
       algorithms to avoid unnecessary (and much more expensive)
       precise computation. As a result, the time complexity of
       handling geometry collection arguments in GIS algorithms
       is reduced from O(N^2) to O(NlogN).

     * Functions for checking spatial relations now use
       functionality available in Boost.Geometry 1.56 and up:
       ST_Contains(), ST_Crosses(), ST_Disjoint(), ST_Equals(),
       ST_Intersects(), ST_Overlaps(), ST_Touches(),
       ST_Within(). Specifically, these functions:

          + Now are able to test the relationship between all
            pairs of argument types handled by Boost.Geometry.

          + Raise an exception for invalid argument types when
            the previous implementation may not have.
       This work also corrected issues that ST_Overlaps()
       returned 1 and ST_Intersects() returned 0 for two
       polygons that shared only a boundary, and that
       ST_Intersects() sometimes incorrectly calculated the
       result for intersections of LineString and Polygon.
       References: See also Bug #68091, Bug #16174580, Bug
       #71076, Bug #17894858.

     * The spatial function namespace is being made more
       consistent, with the ultimate goal that each spatial
       function name begins with ST_ if it performs an exact
       operation, or with MBR if it performs an operation based
       on minimum bounding rectangles.
       Currently, some functions have two implementations and up
       to three related names: A name with an ST_ prefix, and a
       name with an MBR prefix, and a name with no prefix:

          + The name with an ST_ prefix performs an exact

          + The name with an MBR prefix performs an operation
            based on minimum bounding rectangles.

          + The name with neither prefix sometimes is an alias
            for the ST_ name (as with Area() and ST_Area()),
            sometimes an alias for the MBR name (as with
            Contains() and MBRContains()),
       This release implements the following changes in spatial
       function naming:

          + A function with an ST_ prefix is added for each
            non-MBR function that has no ST_ name.

          + Each function that does not begin with ST_ or MBR is

          + The exceptions are the geometry object construction
            functions, which remain unchanged: Point(),
            LineString(), Polygon(), MultiPoint(),
            MultiLineString(), MultiPolygon(), and

          + These functions are deprecated in favor of the MBR
            names: Contains(), Disjoint(), Equals(),
            Intersects(), Overlaps(), Within().

          + These functions are deprecated in favor of the ST_
            names: Area(), AsBinary(), AsText(), AsWKB(),
            AsWKT(), Buffer(), Centroid(), ConvexHull(),
            Crosses(), Dimension(), Distance(), EndPoint(),
            Envelope(), ExteriorRing(), GeomCollFromText(),
            GeomCollFromWKB(), GeomFromText(), GeomFromWKB(),
            GeometryCollectionFromWKB(), GeometryFromText(),
            GeometryFromWKB(), GeometryN(), GeometryType(),
            InteriorRingN(), IsClosed(), IsEmpty(), IsSimple(),
            LineFromText(), LineFromWKB(), LineStringFromText(),
            LineStringFromWKB(), MLineFromText(),
            MLineFromWKB(), MPointFromText(), MPointFromWKB(),
            MPolyFromText(), MPolyFromWKB(),
            MultiLineStringFromText(), MultiLineStringFromWKB(),
            MultiPointFromText(), MultiPointFromWKB(),
            MultiPolygonFromText(), MultiPolygonFromWKB(),
            NumGeometries(), NumInteriorRings(), NumPoints(),
            PointFromText(), PointFromWKB(), PointN(),
            PolyFromText(), PolyFromWKB(), PolygonFromText(),
            PolygonFromWKB(), SRID(), StartPoint(), Touches(),
            X(), Y().

          + These ST_ names are added and are preferred over the
            corresponding non-ST_ names, which now are
            deprecated: ST_GeomCollFromTxt(),
            ST_MLineFromText(), ST_MLineFromWKB(),
            ST_MPointFromText(), ST_MPointFromWKB(),
            ST_MPolyFromText(), ST_MPolyFromWKB(),
            ST_MultiPointFromText(), ST_MultiPointFromWKB(),
            ST_MultiPolygonFromText(), ST_MultiPolygonFromWKB().

          + ST_Length() is added to implement the same operation
            as the now-deprecated GLength(), which has a
            nonstandard name because a function named Length()
            already existed (to calculate string lengths).
       Use of deprecated functions produces a warning. The
       deprecated functions will be removed in a future MySQL

     * These changes have been made for spatial functions that
       operate on minimum bounding rectangles (MBRs) of geometry

          + Two new functions test the covering relationship of
            two geometries using their MBRs. MBRCovers()
            indicates whether the MBR of one geometry covers
            that of another. MBRCoveredBy() tests the opposite,
            indicating whether the MBR of one geometry is
            covered by that of another.

          + The spatial function MBREquals() has been
            implemented. It should be used in preference to
            MBREqual(), which is now deprecated. (The new name
            is more consistent with the similar Equals()

          + MBRTouches() now correctly uses the geometry MBRs,
            not the geometries themselves.

          + MBRTouches() and MBRWithin() better conform to the
            Open Geospatial Consortium specification: When a
            point lies on the boundary of a line segment or
            polygon, or when a line segment lies totally on the
            boundary of a polygon, it is not considered "within"
            but instead "touches." Also, two identical points
            are not considered "touches."

   Functionality Added or Changed

     * Incompatible Change: A new C API function,
       mysql_real_escape_string_quote(), has been implemented as
       a replacement for mysql_real_escape_string() because the
       latter function can fail to properly encode characters
       when the NO_BACKSLASH_ESCAPES SQL mode is enabled. In
       this case, mysql_real_escape_string() cannot escape quote
       characters except by doubling them, and to do this
       properly, it must know more information about the quoting
       context than is available.
       mysql_real_escape_string_quote() takes an extra argument
       for specifying the quoting context. For usage details,
       see mysql_real_escape_string_quote()
       Applications should be modified to use
       mysql_real_escape_string_quote(), instead of
       mysql_real_escape_string(), which now fails and produces
       References: See also Bug #19211994.

     * InnoDB: InnoDB system tablespace data is now exposed in
       Information Schema tables.

     * InnoDB: CHECK TABLE functionality was enhanced for InnoDB
       SPATIAL indexes. Previously, CHECK TABLE only performed
       minimal checks on InnoDB SPATIAL indexes. Enhanced
       functionality includes an R-tree validity check and a
       check to ensure that the R-tree row count matches the
       clustered index.

     * InnoDB: To modularize and decouple the partitioning
       engine from the server code base, partitioning operations
       in the storage engine handler class were moved to a new
       partition_handler base class, which is now the interface
       for partitioning-specific storage engine functionality.

     * InnoDB: The MERGE_THRESHOLD value for index pages is now
       configurable using a COMMENT clause with CREATE TABLE,
       ALTER TABLE, and CREATE INDEX statements. If the
       page-full percentage for an index page falls below the
       MERGE_THRESHOLD value when a row is deleted or when a row
       is shortened by an UPDATE operation, InnoDB attempts to
       merge the index page with a neighboring index page. The
       default MERGE_THRESHOLD value is 50, which is the
       previously hard-coded value.
       For more information, see Configuring the Merge Threshold
       for Index Pages

     * InnoDB: InnoDB now supports native partitioning.
       Previously, InnoDB relied on the ha_partition handler,
       which creates a handler object for each partition. With
       native partitioning, a partitioned InnoDB table uses a
       single partition-aware handler object. This enhancement
       reduces the amount of memory required for partitioned
       InnoDB tables.
       The following changes accompany InnoDB native
       partitioning support:

          + Partition definition (.par) files are no longer
            created. Partition definitions are stored in the
            internal data dictionary.

          + For partitioned InnoDB tables, FLUSH TABLES does not
            reset the "next" AUTO_INCREMENT value. Instead, the
            next AUTO_INCREMENT value is kept and used after the
            FLUSH TABLES operation. If the highest
            AUTO_INCREMENT value is deleted before a FLUSH
            TABLES operation, it is not reused afterwards.

          + Minor changes to statistics could result in changed
            execution plans.

          + The minimum number of rows estimated for a
            partitioned InnoDB table is 1 instead of 2.

          + The minimum number of rows estimated for range read
            on a partitioned InnoDB table index is 0 per
            partition instead of 1.

          + Instead of only including the largest partitions
            when calculating matching rows in an index range,
            all partitions in the read set (after pruning is
            completed) are included. As a result, statistics for
            matching index rows are more accurate, but time
            spent during the Optimizer phase may increase for
            tables with numerous partitions.

     * InnoDB: All remaining code related to the
       innodb_file_io_threads system variable, which was removed
       in MySQL 5.5, was removed from the source code.

     * InnoDB: To support future development, the code that
       initializes, validates and handles tablespace and table
       flags was refactored. Also, the fil_create_ibd_tablespace
       function was refactored, and some functions and variables
       related to single tablespaces were renamed.

     * InnoDB: InnoDB now supports the creation of general
       tablespaces using CREATE TABLESPACE syntax.
CREATE TABLESPACE `tablespace_name`
  ADD DATAFILE 'file_name.ibd'
       General tablespaces can be created outside of the MySQL
       data directory, are capable of holding multiple tables,
       and support tables of all row formats.
       Tables are added to a general tablespace using CREATE
       TABLE tbl_name ... TABLESPACE [=] tablespace_name or
       ALTER TABLE tbl_name TABLESPACE [=] tablespace_name
       For more information about this feature, see CREATE
       TABLESPACE Syntax

     * InnoDB: Replication-related support was added to InnoDB
       that enables prioritization of slave applier transactions
       over other transactions in deadlock scenarios. This
       transaction prioritization mechanism is reserved for
       future use.

     * InnoDB: The default setting for the
       internal_tmp_disk_storage_engine option, which defines
       the storage engine the server uses for on-disk internal
       temporary tables, is now INNODB. With this change, the
       Optimizer uses the InnoDB storage engine instead of
       MyISAM for internal temporary tables. For related
       information,see (see How MySQL Uses Internal Temporary

     * InnoDB: The following buffer pool flushing-related
       enhancements are included in MySQL 5.7.6:

          + The adaptive flushing algorithm flushes all pages at
            the end of the flush list if there is a high
            distribution of pages associated with the oldest

          + The adaptive flushing algorithm gives flushing
            priority to old modified pages in the buffer pool
            instance that contains the greatest number of old
            modified pages.

          + On platforms where it is possible, page_cleaner
            threads are given priority over other MySQL/InnoDB
            threads to help page flushing keep pace with the
            current workload.

          + When the oldest modification LSN is close to the
            defined maximum (max_modified_age_sync), a
            synchronous preflush of buffer pool pages is
            initiated which may result in a "flush wait"
            scenario for user threads. To smooth throughput,
            user threads are now only required to wait for a
            target LSN to be reached instead of waiting for an
            entire flushing batch to finish.

          + A block was added to prevent the log write mechanism
            from overwriting last checkpoint LSN.

          + A message is printed to the server error log if the
            innodb_io_capacity_max setting is too high.

          + New metrics for monitoring page_cleaner thread
            activity were added to the INNODB_METRICS table:
               o buffer_flush_adaptive_avg_pass: Number of
                 adaptive flushes passed during the recent Avg
               o buffer_flush_adaptive_avg_time_est: Estimated
                 time (ms) spent for adaptive flushing recently.
               o buffer_flush_adaptive_avg_time_slot: Avg time
                 (ms) spent for adaptive flushing recently per
               o buffer_flush_adaptive_avg_time_thread: Avg time
                 (ms) spent for adaptive flushing recently per
               o buffer_flush_avg_pass: Number of flushes passed
                 during the recent Avg period.
               o buffer_flush_avg_time: Avg time (ms) spent for
                 flushing recently.
               o buffer_flush_n_to_flush_by_age: Number of pages
                 targeted by LSN Age for flushing.
               o buffer_LRU_batch_flush_avg_pass: Number of LRU
                 batch flushes passed during the recent Avg
               o buffer_LRU_batch_flush_avg_time_est: Estimated
                 time (ms) spent for LRU batch flushing
               o buffer_LRU_batch_flush_avg_time_slot: Avg time
                 (ms) spent for LRU batch flushing recently per
               o buffer_LRU_batch_flush_avg_time_thread: Avg
                 time (ms) spent for LRU batch flushing recently
                 per thread.
               o buffer_LRU_get_free_loops: Total loops in LRU
                 get free.
               o buffer_LRU_get_free_waits: Total sleep waits in
                 LRU get free.

     * InnoDB: InnoDB now provides a built-in full-text ngram
       parser plugin that supports Chinese, Japanese, and Korean
       (CJK), and an installable MeCab full-text parser plugin
       for Japanese.
       For more information see InnoDB ngram Full-Text Parser
       and InnoDB MeCab Full-Text Parser Plugin

     * InnoDB: The Performance Schema now instruments stage
       events for monitoring InnoDB ALTER TABLE and buffer pool
       load operations. The new stage events include:

          + stage/innodb/alter table (read PK and internal sort)

          + stage/innodb/alter table (merge sort)

          + stage/innodb/alter table (insert)

          + stage/innodb/alter table (flush)

          + stage/innodb/alter table (log apply index)

          + stage/innodb/alter table (log apply table)

          + stage/innodb/alter table (end)

          + stage/innodb/buffer pool load
       For more information, see InnoDB Integration with MySQL
       Performance Schema
       and Preloading the InnoDB Buffer Pool for Faster Restart

     * InnoDB: InnoDB now supports 32KB and 64KB page sizes. For
       both page sizes, the maximum record size is 16KB.
       ROW_FORMAT=COMPRESSED is not supported when
       innodb_page_size is set to 32k or 64k. For
       innodb_page_size=32k, extent size is 2MB. For
       innodb_page_size=64k, extent size is 4MB.

     * Replication: The variable binlogging_impossible_mode has
       been renamed binlog_error_action.
       binlogging_impossible_mode is now deprecated. (Bug

     * Replication: When using InnoDB with binary logging
       enabled, concurrent transactions written in the InnoDB
       redo log are now grouped together before synchronizing to
       disk when innodb_flush_log_at_trx_commit is set to 1,
       which reduces the amount of synchronization operations.
       This can lead to improved performance. (Bug #19424075)

     * Replication: There is now a Previous_gtids event in every
       binary log, regardless of the value of gtid_mode. In
       previous versions, it was only generated when
       gtid_mode=on. Similarly, there is now an Anonymous_gtid
       event before every transaction when gtid_mode=off. These
       changes ensure that similar per-transaction events are
       generated regardless of the type of binary logging in
       use. As well as enabling the newly added ability to
       change gtid_mode online, this also has a positive impact
       on the recovery of gtid_purged and gtid_executed.

     * Replication: It is now possible to change replication
       mode without having to shut down the server or
       synchronize the topology. As part of this feature, the
       following changes have been made:

          + The variable gtid_mode is now dynamic. It can be set
            by SUPER from a top-level statement. The states
            OFF_PERMISSIVE and ON_PERMISSIVE have been added.

          + The variable enforce_gtid_consistency is now
            dynamic. It can be set by SUPER from a top-level

          + The status variable
            Ongoing_anonymous_transaction_count has been
            introduced. This shows the number of ongoing
            transactions which have been marked as anonymous.

          + The status variables
            have been introduced in debug-enabled builds. They
            are not available in non-debug builds. These
            variables count the number of ongoing transactions
            that violate GTID consistency, which use
            gtid_next=ANONYMOUS and gtid_next=AUTOMATIC,

     * Replication: A new more general purpose parallelization
       algorithm is now used when
       slave_parallel_type=LOGICAL_CLOCK, replacing the previous
       algorithm that was limited to transactions on different
       databases. This improves throughput when transactions on
       the master do not depend on each other. Now even two
       concurrent transactions on a master can execute in
       parallel on a slave, if they hold all of their locks on
       the master. Additionally, transaction dependency is now
       tracked on the slave through extra fields added to
       replication transactions in the binary log.

     * Undocumented functions in the C client library now are
       hidden. This help minimize namespace pollution, and
       permits linking for applications that require functions
       both from yaSSL (in the client library) and from OpenSSL.
       (Bug #20476596)

     * CMake support was updated to handle CMake version 3.1.
       (Bug #20344207)

     * Previously, debug builds on Windows were built with /Ob0,
       which disables function inlining. Builds now use /Ob1 to
       enable inlining. The new WIN_DEBUG_NO_INLINE CMake option
       can be used to control inlining. The default value is OFF
       (inlining enabled); if set to ON, inlining is disabled.
       (Bug #20316320)

     * yaSSL was upgraded to version 2.3.7. (Bug #19695101, Bug

     * The new -DWITH_UBSAN=ON CMake option enables the
       Undefined Behavior Sanitizer. This feature is supported
       by GCC 4.9 and up, and Clang 3.4 and up. (Bug #19587393)

     * The valid date range of the SSL certificates in
       mysql-test/std_data has been extended to the year 2029.
       (Bug #18366947)

     * Overhead was reduced for queries such as tested by the
       sysbench "order-by-range" test. (Bug #75390, Bug

     * The mysql client program now supports \C in the prompt
       command to signify the current connection identifier.
       Thanks to Tsubasa Tanaka for the patch. (Bug #75242, Bug

     * The server now includes its version number when it writes
       the initial "starting" message to the error log, to make
       it easier to tell which server instance error log output
       applies to. This value is the same as that available from
       the version system variable. (Bug #74917, Bug #20052694)

     * The required version of the Boost library for server
       builds has been raised from 1.55.0 to 1.57.0. (Bug
       #74666, Bug #19940297, Bug #73432, Bug #19320102)

     * Previously, the auth_socket authentication plugin checked
       the socket user name only against the MySQL user name
       specified by the client program to the server. Now, if
       those names do not match, the plugin also checks whether
       the socket user name matches the name specified in the
       authentication_string column of the mysql.user table row.
       The plugin permits the connection for a match in either
       case. Thanks to Daniël van Eeden for the patch. (Bug
       #74586, Bug #20041925)

     * The libmysqlclient version number has been incremented to
       20.0.0. (Bug #74206, Bug #19729266)

     * A new CMake option, WITH_MSCRT_DEBUG, is available to
       control Visual Studio CRT memory leak tracing. The
       default is OFF. (Bug #73064, Bug #19031370)

     * Beginning with MySQL 5.7.2, the server disables at
       startup any account that has no authentication plugin.
       The server now writes a more extensive message to the
       error log in this case to indicate how to reenable such
       accounts. (Bug #73026, Bug #19011337)

     * ALTER TABLE did not take advantage of fast alterations
       that might otherwise apply to the operation to be
       performed, if the table contained temporal columns found
       to be in pre-5.6.4 format (TIME, DATETIME, and TIMESTAMP
       columns without support for fractional seconds
       precision). Instead, it upgraded the table by rebuilding
       it. Two new system variables enable control over
       upgrading such columns and provide information about

          + avoid_temporal_upgrade controls whether ALTER TABLE
            implicitly upgrades temporal columns found to be in
            pre-5.6.4 format. This variable is disabled by
            default. Enabling it causes ALTER TABLE not to
            rebuild temporal columns and thereby be able to take
            advantage of possible fast alterations.

          + show_old_temporals controls whether SHOW CREATE
            TABLE output includes comments to flag temporal
            columns found to be in pre-5.6.4 format. Output for
            the COLUMN_TYPE column of the
            INFORMATION_SCHEMA.COLUMNS table is affected
            similarly. This variable is disabled by default.
       Both variables are deprecated and will be removed in a
       future MySQL release. (Bug #72997, Bug #18985760)

MySQL Community Server 5.7.6 has been released (part 1/3)Bjorn Munch10 Mar