Dear MySQL users,

MySQL Server 5.6.2 (Milestone Release) is a new version of the world's
most popular open source database.

The new features in these releases are of beta quality. 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.6.2 includes all features in MySQL 5.5. For an overview of
what's new in MySQL 5.6, please see the section "What Is New in MySQL
5.6" below, or view it online at

    http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html

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

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

For upgrading from previous MySQL releases, please see the important
upgrade considerations at

http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html

Please note that *downgrading* from these releases to a previous release
series is not supported.

MySQL Server 5.6 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/

Not all mirror sites may be up to date at this point in time, so if you
can't find this version on some mirror, please try again later or choose
another download site.

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

     http://forge.mysql.com/wiki/Contributing

The list of all "Bugs Fixed" for 5.6.2 may also be viewed online at

     http://dev.mysql.com/doc/refman/5.6/en/news-5-6-2.html

If you are running a MySQL production level system, we would like to
direct your attention to MySQL Enterprise Edition, which includes the
most comprehensive set of MySQL production, backup, monitoring,
modeling, development, and administration tools so businesses can
achieve the highest levels of MySQL performance, security and uptime.

     http://mysql.com/products/enterprise/


D.1.2. Changes in MySQL 5.6.2 (11 April 2011)

   Explicit Partition Selection

     * Partitioning: It is now possible to select one or more
       partitions or subpartitions when querying from a partitioned
       table. In addition, many data modification statements (DELETE,
       INSERT, REPLACE, UPDATE, LOAD DATA, and LOAD XML) that act on
       partitioned tables also now support explicit partition
       selection. For example, assume we have a table named t with
       some integer column named c, and t has 4 partitions named p0,
       p1, p2, and p3. Then the query SELECT * FROM t PARTITION (p0,
       p1) WHERE c < 5 returns rows only in partitions p0 and p1 that
       match the WHERE condition, while partitions p2 and p3 are not
       checked.
       For additional information and examples, see Section 16.5,
       "Partition Selection," as well as the descriptions of the
       statements just listed.

   Row Image Control

     * Replication: Added the binlog_row_image server system
       variable, which can be used to enable row image control for
       row-based replication. This means that you can potentially
       save disk space, network resources, and memory usage by the
       MySQL Server by logging only those columns that are required
       for uniquely identifying rows, or which are actually changed
       on each row, as opposed to logging all columns for each and
       every row change event. In addition, you can use a "noblob"
       mode where all columns, except for unneeded BLOB or TEXT
       columns, are logged.
       For more information, see Section 15.1.3.4, "System variables
       used with the binary log." (Bug #47200, Bug #11755426, Bug
       #47303, Bug #56917, Bug #11755426, Bug #11755513, Bug
       #11764116)

   Crash-Safe Binary Log

     * Replication: Support for checksums when writing and reading
       the binary log is added to the MySQL Server. Writing checksums
       into the binary log is disabled by default; it can be enabled
       by starting the server with the --binlog-checksum option. To
       cause the server to read checksums from the binary log, start
       the server with the --master-verify-checksum option. The
       --slave-sql-verify-checksum option causes the slave to read
       checksums from the relay log.

     * Replication: The MySQL Server now records and reads back only
       complete events or transactions to and from the binary log. By
       default, the server now logs the length of the event as well
       as the event itself and uses this information to verify that
       the event was written correctly to the log. A master also uses
       by default this value to verify events when reading from the
       binary log.
       If you enable writing of checksums (using the binlog_checksum
       system variable), the master can use these instead by enabling
       the master_verify_checksum system variable. The slave I/O
       thread also verifies events received from the master. You can
       cause the slave SQL thread to use checksums (if available) as
       well, when reading from the relay log, by enabling the
       slave_sql_verify_checksum system variable on the slave.

   Slave Log Tables

     * Replication: It is now possible to write information about the
       slave connection to the master and about the slave's execution
       point within the relay log to tables rather than files.
       Logging of master connection information and of slave relay
       log information to tables can be done independently of one
       another; this is controlled by the --master-info-repository
       and --relay-log-info-repository server options. When
       --master-info-repository is set to TABLE, connection
       information is logged in the slave_master_info table in the
       mysql system database. When --relay-log-info-repository is set
       to TABLE, relay log information is logged to the
       slave_relay_log_info table, also in the mysql database.

   Globally Unique Server IDs

     * Replication: Implemented globally unique IDs for MySQL
       servers. A UUID is now obtained automatically when the MySQL
       server starts. The server first checks for a UUID written in
       the auto.cnf file (in the server's data directory), and uses
       this UUID if found. Otherwise, the server generates a new UUID
       and saves it to this file (and creates the file if it does not
       already exist). This UUID is available as the server_uuid
       system variable.
       MySQL replication masters and slaves know each other's UUIDs.
       The value of a slave's UUID can be read on the master as the
       system variable slave_uuid, as well as in the output of SHOW
       SLAVE HOSTS. After a slave is started (with START SLAVE), the
       value of the master's UUID is available on the slave as the
       master_uuid system variable, as well as in the output of SHOW
       SLAVE STATUS.
       For more information, see Section 15.1.3, "Replication and
       Binary Logging Options and Variables." (Bug #33815, Bug
       #11747723)
       See also Bug #16927, Bug #11745543.

   Optimizer Features

     * The optimizer now more efficiently handles queries (and
       subqueries) of the following form:
        SELECT ... FROM single_table ... ORDER BY non_index_column
        [DESC] LIMIT N;
       That type of query is common in web applications that display
       only a few rows from a larger result set. For example:
        SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;
        SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;
       If the sort elements for N rows are small enough to fit in the
       sort buffer, which has a size of sort_buffer_size, the server
       can avoid using a merge file and perform the sort entirely in
       memory. For details, see Section 7.2.1.3, "Optimizing LIMIT
       Queries."

     * The optimizer implements Disk-Sweep Multi-Range Read. Reading
       rows using a range scan on a secondary index can result in
       many random disk accesses to the base table when the table is
       large and not stored in the storage engine's cache. With the
       Disk-Sweep Multi-Range Read (MRR) optimization, MySQL tries to
       reduce the number of random disk access for range scans by
       first scanning the index only and collecting the keys for the
       relevant rows. Then the keys are sorted and finally the rows
       are retrieved from the base table using the order of the
       primary key. The motivation for Disk-sweep MRR is to reduce
       the number of random disk accesses and instead achieve a more
       sequential scan of the base table data. For more information,
       see Section 7.13.10, "Multi-Range Read Optimization."

     * The optimizer implements Index Condition Pushdown (ICP), an
       optimization for the case where MySQL retrieves rows from a
       table using an index. Without ICP, the storage engine
       traverses the index to locate rows in the base table and
       returns them to the MySQL server which evaluates the WHERE
       condition for the rows. With ICP enabled, and if parts of the
       WHERE condition can be evaluated by using only fields from the
       index, the MySQL server pushes this part of the WHERE
       condition down to the storage engine. The storage engine then
       evaluates the pushed index condition by using the index entry
       and only if this is satisfied is base row be read. ICP can
       reduce the number of accesses the storage engine has to do
       against the base table and the number of accesses the MySQL
       server has to do against the storage engine. For more
       information, see Section 7.13.4, "Index Condition Pushdown
       Optimization."

   Performance Schema Notes

     * The Performance Schema has these additions:

          + The Performance Schema now has tables that contain
            summaries for table and index I/O wait events, as
            generated by the wait/io/table/sql/handler instrument:
               o table_io_waits_summary_by_table aggregates table I/O
                 wait events. The grouping is by table.
               o table_io_waits_summary_by_index_usage aggregates
                 table index I/O wait events. The grouping is by
                 table index.
            The information in these tables can be used to assess the
            impact of table I/O performed by applications. For
            example, it is possible to see which tables are used and
            which indexes are used (or not used), or to identify
            bottlenecks on a table when multiple applications access
            it. The results may be useful to change how applications
            issue queries against a database, to minimize application
            footprint on the server and to improve application
            performance and scalability.
            A change that accompanies the new tables is that the
            events_waits_current table now has an INDEX_NAME column
            to identify which index was used for that operation that
            generated the event. The same is true of the
            event-history tables, events_waits_history, and
            events_waits_history_long.

          + The Performance Schema now has an instrument named
            wait/lock/table/sql/handler in the setup_instruments
            table for instrumenting table lock wait events. It
            differs from wait/io/table/sql/handler, which instruments
            table I/O. This enables independent instrumentation of
            table I/O and table locks.
            Accompanying the new instrument, the Performance Schema
            has a table named table_lock_waits_summary_by_table that
            aggregates table lock wait events, as generated by the
            new instrument. The grouping is by table.
            The information in this table may be used to assess the
            impact of table locking performed by applications. The
            results may be useful to change how applications issue
            queries against the database and use table locks, to
            minimize the application footprint on the server and to
            improve application performance and scalability. For
            example, an application locking tables for a long time
            may negatively affect other applications, and the
            instrumentation makes this visible.

          + To selectively control which tables are instrumented for
            I/O and locking, use the setup_objects table. See Section
            19.3.1.2, "Pre-Filtering by Object."

          + The setup_consumers table contents have changed.
            Previously, the table used a "flat" structure with a
            one-to-one correspondence between consumer name and
            destination table. This has been replaced with a
            hierarchy of consumer settings that enable progressively
            finer control of which destinations receive events. The
            previous xxx_summary_xxx consumers no longer exist.
            Instead, the Performance Schema maintains appropriate
            summaries automatically for the levels are which settings
            in the consumer hierarchy are enabled. For example, if
            only the top-level (global) consumer is enabled, only
            global summaries are maintained. Others, such as
            thread-level summaries, are not. See Section 19.3.1.4,
            "Pre-Filtering by Consumer." In addition, optimizations
            have been added to reduce Performance Schema overhead.

          + It is now possible to filter events by object using the
            new setup_objects table. Currently, this table can be
            used to selectively instrument tables, based on schema
            names and/or table names. See Section 19.3.1.2,
            "Pre-Filtering by Object." A new table,
            objects_summary_global_by_type, summarizes events for
            objects.

          + It is now possible to filter events by thread, and the
            Performance Schema collects more information for each
            thread. A new table, setup_actors, can be used to
            selectively instrument user connections, based on the
            user name and/or host name of each connecting session.
            The threads table, which contains a row for each active
            server thread, was extended with several new columns.
            With these additions, the information available in
            threads is like that available from the
            INFORMATION_SCHEMA.PROCESSLIST table or the output from
            SHOW PROCESSLIST. Thus, all three serve to provide
            information for thread-monitoring purposes. Use of
            threads differs from use of the other two thread
            information sources in these ways:
               o Access to threads does not require a mutex and has
                 minimal impact on server performance.
                 INFORMATION_SCHEMA.PROCESSLIST and SHOW PROCESSLIST
                 have negative performance consequences because they
                 require a mutex.
               o threads provides additional information for each
                 thread, such as whether it is a foreground or
                 background thread, and the location within the
                 server associated with the thread.
               o threads provides information about background
                 threads. This means that threads can be used to
                 monitor activity the other thread information
                 sources cannot.
               o You can control which threads are monitored by
                 setting the INSTRUMENTED column or by using the
                 setup_actors table.
            For these reasons, DBAs who perform server monitoring
            using INFORMATION_SCHEMA.PROCESSLIST or SHOW PROCESSLIST
            may wish to monitor using threads instead.

       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.
       For more information, see Chapter 19, "MySQL Performance
       Schema."


   Functionality added or changed:

     * Incompatible Change: The following obsolete constructs have
       been removed. Where alternatives are shown, applications
       should be updated to use them.

          + The FLUSH MASTER and FLUSH SLAVE statements. Use the
            RESET MASTER and RESET SLAVE statements instead.

          + The --log server option and the log system variable.
            Instead, use the --general_log option to enable the
            general query log and the --general_log_file=file_name
            option to set the general query log file name.

          + The --log-slow-queries server option and the
            log_slow_queries system variable. Instead, use the
            --slow_query_log option to enable the slow query log and
            the --slow_query_log_file=file_name option to set the
            slow query log file name.

          + The --one-thread server option. Use
            --thread_handling=no-threads instead.

          + The --skip-thread-priority server option.

          + The engine_condition_pushdown system variable. Use the
            engine_condition_pushdown flag of the optimizer_switch
            variable instead.

          + The have_csv, have_innodb, have_ndbcluster
            (http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-sys
            tem-variables.html#sysvar_have_ndbcluster), and
            have_partitioning system variables. Use SHOW ENGINES
            instead.

          + The sql_big_tables system variable. Use big_tables
            instead.

          + The sql_low_priority_updates system variable. Use
            low_priority_updates instead.

          + The sql_max_join_size system variable. Use max_join_size
            instead.

          + The SLAVE START and SLAVE STOP statements. Use the START
            SLAVE and STOP SLAVE statements instead.

          + The ONE_SHOT modifier for the SET statement.

     * Important Change: Replication: Replication filtering options
       such as --replicate-do-db, --replicate-rewrite-db, and
       --replicate-do-table were not consistent with one another in
       regard to case sensitivity. Now all --replicate-* options
       follow the same rules for case sensitivity applying to names
       of databases and tables elsewhere in the MySQL server,
       including the effects of the lower_case_table_names system
       variable. (Bug #51639, Bug #11759334)

     * Important Change: Replication: Added the MASTER_RETRY_COUNT
       option to the CHANGE MASTER TO statement, and a corresponding
       Master_Retry_Count column to the output of SHOW SLAVE STATUS.
       The option sets the value shown in this column.
       MASTER_RETRY_COUNT is intended eventually to replace the older
       --master-retry-count server option, and is now the preferred
       method for setting the maximum number of times that the slave
       may attempt to reconnect after losing its connection to the
       master. (Bug #44209, Bug #11752887, Bug #44486, Bug #11753110)

     * Important Change: Replication: Added the
       --binlog-rows-query-log-events option for mysqld. Using this
       option causes a server logging in row-based mode to write
       informational rows query log events (SQL statements, for
       debugging and other purposes) to the binary log. MySQL server
       and MySQL programs from MySQL 5.6.2 and later normally ignore
       such events, so that they do not pose an issue when reading
       the binary log. mysqld and mysqlbinlog from previous MySQL
       releases cannot read such events in the binary log, and fail
       if they attempt to do so. For this reason, you should never
       prepare logs for a MySQL 5.6.1 or earlier replication slave
       server (or other reader such as mysqlbinlog) with this option
       enabled on the master. (Bug #11758695, Bug #50935, Bug
       #11758695)

     * Replication: SHOW SLAVE STATUS now displays the actual number
       of retries for each connection attempt made by the I/O thread.
       (Bug #56416, Bug #11763675)

     * Replication: Added the Slave_last_heartbeat status variable,
       which shows when a replication slave last received a heartbeat
       signal. The value is displayed using TIMESTAMP format. (Bug
       #45441)

     * Replication: Timestamps have been added to the output of SHOW
       SLAVE STATUS to show when the most recent I/O and SQL thread
       errors occurred. The Last_IO_Error column is now prefixed with
       the timestamp for the most recent I/O error, and
       Last_SQL_Error shows the timestamp for the most recent SQL
       thread error. The timestamp values use the format YYMMDD
       HH:MM:SS in both of these columns. For more information, see
       Section 12.4.5.35, "SHOW SLAVE STATUS Syntax." (Bug #43535,
       Bug #11752361)

     * Replication: On MySQL replication slaves having multiple
       network interfaces, it is now possible to set which interface
       to use for connecting to the master using the
       MASTER_BIND='interface' option in a CHANGE MASTER TO
       statement.
       The value set by this option can be seen in the Master_Bind
       column of the output from SHOW SLAVE STATUS or the Bind column
       of the mysql.slave_master_info table. (Bug #25939, Bug
       #11746389)

     * Replication: Added the log_bin_basename system variable, which
       contains the complete filename and path to the binary log
       file. (The log_bin system variable shows only whether or not
       binary logging is enabled; log_bin_basename, however, reflects
       the name set with the --log-bin server option.) Also added
       relay_log_basename system variable, which shows the filename
       and complete path to the relay log file.
       See also Bug #19614, Bug #11745759.

     * Changes to replication in MySQL 5.6 make mysqlbinlog output
       generated by the --base64-output=ALWAYS option unusable.
       ALWAYS is now an invalid value for this option. If the option
       is given without a value, the effect is now the same as
       --base64-output=AUTO rather than --base64-output=ALWAYS.
       See also Bug #28760, Bug #11746794.

     * Replication: The SHOW SLAVE STATUS statement now has a
       Master_Info_File field indicating the location of the
       master.info file. (Bug #50316, Bug #11758151)

     * Replication: MySQL now supports delayed replication such that
       a slave server deliberately lags behind the master by at least
       a specified amount of time. The default delay is 0 seconds.
       Use the new MASTER_DELAY option for CHANGE MASTER TO to set
       the delay to N seconds:
        CHANGE MASTER TO MASTER_DELAY = N;
       An event received from the master is not executed until at
       least N seconds later than its execution on the master.
       START SLAVE and STOP SLAVE take effect immediately and ignore
       any delay. RESET SLAVE resets the delay to 0.
       SHOW SLAVE STATUS has three new fields that provide
       information about the delay:

          + SQL_Delay: The number of seconds that the slave must lag
            the master.

          + SQL_Remaining_Delay: When Slave_SQL_Running_State is
            Waiting until MASTER_DELAY seconds after master executed
            event, this field contains the number of seconds left of
            the delay. At other times, this field is NULL.

          + Slave_SQL_Running_State: The state of the SQL thread
            (analogous to Slave_IO_State). The value is identical to
            the State value of the SQL thread as displayed by SHOW
            PROCESSLIST.
       When the slave SQL thread is waiting for the delay to elapse
       before executing an event, SHOW PROCESSLIST displays its State
       value as Waiting until MASTER_DELAY seconds after master
       executed event.
       The relay-log.info file now contains the delay value, so the
       file format has changed. See Section 15.2.2.2, "Slave Status
       Logs." In particular, the first line of the file now indicates
       how many lines are in the file. If you downgrade a slave
       server to a version older than MySQL 5.6, the older server
       will not read the file correctly. To address this, modify the
       file in a text editor to delete the initial line containing
       the number of lines.
       The introduction of delayed replication entails these
       restrictions:

          + Previously the BINLOG statement could execute all types
            of events. Now it can execute only format description
            events and row events.

          + The output from mysqlbinlog --base64-output=ALWAYS cannot
            be parsed. ALWAYS becomes an invalid value for this
            option in 5.6.1.
       For additional information, see Section 15.3.9, "Delayed
       Replication." (Bug #28760, Bug #11746794)

     * The Performance Schema now includes instrumentation for table
       input and output. Instrumented operations include row-level
       accesses to persistent base tables or temporary tables.
       Operations that affect rows are fetch, insert, update, and
       delete. For a view, waits are associated with base tables
       referenced by the view.

     InnoDB Configurable Data Dictionary cache

     * InnoDB Storage Engine: InnoDB now uses the table_cache option
       value as a guide to remove table metadata from memory when
       many different InnoDB tables are accessed. InnoDB table
       metadata is removed using a variation of the LRU algorithm.
       (Parent and child tables in foreign key relationships are
       exempted from removal.) (Bug #20877, Bug #11745884)

     INFORMATION_SCHEMA Table for InnoDB Metrics

     * InnoDB Storage Engine: A new INFORMATION_SCHEMA table,
       INNODB_METRICS, lets you query low-level InnoDB performance
       information, getting cumulative counts, averages, and min/max
       values for internal aspects of the storage engine operation.
       You can start, stop, and reset the metrics counters using the
       configuration variables innodb_monitor_enable,
       innodb_monitor_disable, innodb_monitor_reset, and
       innodb_monitor_reset_all.

     INFORMATION_SCHEMA Tables for InnoDB Buffer Pool Information

     * InnoDB Storage Engine: The new INFORMATION_SCHEMA tables
       INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and
       INNODB_BUFFER_POOL_STATS display InnoDB buffer pool
       information for tuning on large-memory or highly loaded
       systems.

     INFORMATION_SCHEMA Tables for InnoDB Data Dictionary

     * InnoDB Storage Engine: The InnoDB data dictionary, containing
       metadata about InnoDB tables, columns, indexes, and foreign
       keys, is available for SQL queries through a set of
       INFORMATION_SCHEMA tables.

     Persistent InnoDB Optimizer Statistics

     * InnoDB Storage Engine: The optimizer statistics for InnoDB
       tables can now persist across server restarts, producing more
       stable query performance. You can also control the amount of
       sampling done to estimate cardinality for each index,
       resulting in more accurate optimizer statistics.

     * InnoDB Storage Engine: InnoDB can optionally log details about
       all deadlocks that occur, to assist with troubleshooting and
       diagnosis. This feature is controlled by the
       innodb_print_all_deadlocks configuration option. (Bug #1784,
       , Bug #11744783, Bug #17572)

     * InnoDB Storage Engine: A separate InnoDB thread (page_cleaner)
       now handles the flushing of dirty pages that was formerly done
       by the InnoDB master thread.

     * InnoDB Storage Engine: The configuration option
       innodb_purge_threads can now be set to a value higher than 1.

     * InnoDB Storage Engine: The InnoDB kernel mutex has been split
       into several mutexes and rw-locks, for improved concurrency.

     * Windows provides APIs based on UTF-16LE for reading from and
       writing to the console. MySQL now supports a utf16le character
       set for UTF-16LE, so the mysql client for Windows has been
       modified to provide improved Unicode support by using these
       APIs.
       To take advantage of this change, you must run mysql within a
       console that uses a compatible Unicode font and set the
       default character set to a Unicode character set that is
       supported for communication with the server. For instructions,
       see Section 4.5.1.6.1, "Unicode Support on Windows."

     * Several changes were made to optimizer-related system
       variables:

          + The optimizer_switch system variable has new
            engine_condition_pushdown and index_condition_pushdown
            flags to control whether storage engine condition
            pushdown and index condition pushdown optimizations are
            used. The engine_condition_pushdown system variable now
            is deprecated. For information about condition pushdown,
            see Section 7.13.3, "Engine Condition Pushdown
            Optimization," and Section 7.13.4, "Index Condition
            Pushdown Optimization."

          + The optimizer_switch system variable has new mrr and
            mrr_cost_based flags to control use of the Multi-Range
            Read optimization. The optimizer_use_mrr system variable
            has been removed. For information about Multi-Range Read,
            see Section 7.13.10, "Multi-Range Read Optimization."

          + The join_cache_level system variable has been renamed to
            optimizer_join_cache_level. This enables SHOW VARIABLES
            LIKE 'optimizer%' to show more optimizer-related
            settings.

     * In MySQL 5.5, setting optimizer_search_depth to the deprecated
       value of 63 switched to the algorithm used in MySQL 5.0.0 (and
       previous versions) for performing searches. The value of 63 is
       now treated as invalid.


     * The Unicode implementation has been extended to a utf16le
       character set, which corresponds to the UTF-16LE encoding of
       the Unicode character set. This is similar to utf16 (UTF16)
       but is little-endian rather than big-endian.
       utf16le has two collations available:

          + utf16le_general_ci: The default collation, case sensitive
            (similar to utf16_general_ci.

          + utf16le_bin: Case sensitive, with by-codepoint comparison
            that provides the same order as utf16_bin.
       There are some limitations on the use of utf16le. With the
       exception of the item regarding user-defined collations, these
       are the same as the limitations on ucs2, utf16, and utf32.

          + utf16le cannot be used as a client character set, which
            means that it also does not work for SET NAMES or SET
            CHARACTER SET.

          + It is not possible to use LOAD DATA INFILE to load data
            files that use utf16le.

          + FULLTEXT indexes cannot be created on a column that uses
            utf16le. However, you can perform IN BOOLEAN MODE
            searches on the column without an index.

          + The use of ENCRYPT() with utf16le is not recommended
            because the underlying system call expects a string
            terminated by a zero byte.

          + It is not possible to create user-defined UCA collations
            for utf16le because there is no utf16le_unicode_ci
            collation, which would serve as the basis for such
            collations.

     * Unicode collation names now may include a version number to
       indicate the Unicode Collation Algorithm (UCA) version on
       which the collation is based. Initial collations thus created
       use version UCA 5.2.0. For example, utf8_unicode_520_ci is
       based on UCA 5.2.0. UCA-based Unicode collation names that do
       not include a version number are based on version 4.0.0.
       LOWER() and UPPER() perform case folding according to the
       collation of their argument. A character that has uppercase
       and lowercase versions only in a Unicode version more recent
       than 4.0.0 will be converted by these functions only if the
       argument has a collation that uses a recent enough UCA
       version.
       The LDML rules for creating user-defined collations are
       extended to permit an optional version attribute in
       <collation> tags to indicate the UCA version on which the
       collation is based. If the version attribute is omitted, its
       default value is 4.0.0. See Section 9.4.4, "Adding a UCA
       Collation to a Unicode Character Set."

     * Croatian collations were added for Unicode character sets:
       utf8_croatian_ci, ucs2_croatian_ci, utf8mb4_croatian_ci,
       utf16_croatian_ci, and utf32_croatian_ci. Thee collations have
       tailoring for Croatian letters: Č, Ć, Dž, �, Lj, Nj, Š, Ž.
       They are based on Unicode 4.0.

     * Vietnamese collations were added for the Unicode character
       sets. Those based on Unicode Collation Algorithm 5.2.0 have
       names of the form xxx_vietnamese_520_ci (for example,
       utf8_vietnamese_520_ci). Those based on Unicode Collation
       Algorithm 4.0.0 have names of the form xxx_vietnamese_ci (for
       example, utf8_vietnamese_ci). These collations are the same as
       the corresponding xxx_unicode_520_ci and xxx_unicode_ci
       collations except for precomposed characters which are
       accented versions of "A", "D", "E", "O", and "U". There is no
       change to ideographic characters derived from Chinese. There
       are no digraphs.


     * The Unicode character sets now have a xxx_german2_ci collation
       that provides DIN-2 (phone book) ordering (for example,
       utf8_german2_ci). See Section 9.1.14.1, "Unicode Character
       Sets."

     * The Romansh locale 'rm_CH' is now a permissible value for the
       lc_time_names system variable. (Bug #50915, Bug #11758678)

     * Partitioning: It is now possible to exchange a partition of a
       partitioned table or a subpartition of a subpartitioned table
       with a nonpartitioned table that otherwise has the same
       structure using the ALTER TABLE ... EXCHANGE PARTITION
       statement. This can be used, for example, for importing and
       exporting partitions.
       For more information and examples, see Section 16.3.3,
       "Exchanging Partitions and Subpartitions with Tables."

     * The mysql_upgrade, mysqlbinlog, mysqlcheck, mysqlimport,
       mysqlshow, and mysqlslap clients now have --default-auth and
       --plugin-dir options for specifying which authentication
       plugin and plugin directory to use. (Bug #58139, Bug #11765201)

     * mysqlbinlog now has a --binlog-row-event-max-size option to
       enable large row events to be read from binary log files. (Bug
       #49932)

     * mysqlbinlog now has the capability to back up a binary log in
       its original binary format. When invoked with the
       --read-from-remote-server and --raw options, mysqlbinlog
       connects to a server, requests the log files, and writes
       output files in the same format as the originals. See Section
       4.6.7.3, "Using mysqlbinlog to Back Up Binary Log Files."

     * mysqldump now has an --add-drop-trigger option which adds a
       DROP TRIGGER IF EXISTS statement before each dumped trigger
       definition. (Bug #34325, Bug #11747863)

    * mysqldump --xml now displays comments from column definitions.
       (Bug #13618, Bug #11745324)

    * A new SQL function, WEIGHT_STRING(), returns the weight string
       for an input string. The weight string represents the sorting
       and comparison value of the input string.

    * MySQL distributions now include auth_socket, a server-side
       authentication plugin that authenticates clients that connect
       from the local host through the Unix socket file. The plugin
       uses the SO_PEERCRED socket option to obtain information about
       the user running the client program (and thus can be built
       only on systems that support this option. For a connection to
       succeed, the plugin requires a match between the login name of
       the connecting client user and the MySQL user name presented
       by the client program. For more information, see Section
       5.5.6.1.4, "The Socket Peer-Credential Authentication Plugin."
       (Bug #59017, Bug #11765993)

     * Boolean system variables can be enabled at run time by setting
       them to the value ON or OFF, but previously this did not work
       at server startup. Now at startup such variables can be
       enabled by setting them to ON or TRUE, or disabled by setting
       them to OFF or FALSE. Any other nonnumeric variable is
       invalid. (Bug #46393, Bug #11755200)
       See also Bug #11754743, Bug #51631.

     * Previously, for queries that were aborted due to a sort
       problem, the server wrote the message Sort aborted to the
       error log. Now the server writes more information to provide a
       more specific message, such as:
        Sort aborted: Out of memory (Needed 24 bytes)
        Out of sort memory, consider increasing server sort buffer size
        Sort aborted: Out of sort memory, consider increasing
        server sort buffer size
        Sort aborted: Incorrect number of arguments for FUNCTION
        test.f1; expected 0, got 1
       In addition, if the server was started with --log-warnings=2,
       the server write information about the host, user, and query.
       (Bug #36022, Bug #11748358)

     * Previously, for queries that were aborted due to a sort
       problem or terminated with KILL in the middle of a sort, the
       server wrote the message Sort aborted to the error log. Now
       the server writes more information about the cause of the
       error. These causes include:
        Insufficient disk space in tmpdir prevented tmpfile from
          being created
        Insufficient memory for sort_buffer_size to be allocated
        Somebody ran KILL id in the middle of a filesort
        The server was shutdown while some queries were sorting
        A transaction got rolled back or aborted due to lock wait
          timeout or deadlock
        Unexpected errors, such as source table or even tmp table was
        corrupt processing of a subquery failed which was also sorting
       (Bug #30771, Bug #11747102)

     * The undocumented SHOW NEW MASTER statement has been removed.

     * MySQL distributions now include mysql_clear_password, a
       client-side authentication plugin that sends the password to
       the server without hashing or encryption. Although this is
       insecure, and thus appropriate precautions should be taken
       (such as using an SSL connection), the plugin is useful in
       conjunction with server-side plugins that must have access to
       the original password in clear text. For more information, see
       Section 5.5.6.1.3, "The Clear Text Client-Side Authentication
       Plugin."

     * A new plugin service, my_plugin_log_service, enables plugins
       to report errors and specify error messages. The server writes
       the messages to the error log. See Section 21.2.6, "MySQL
       Services for Plugins."

     * There is now a bind_address system variable containing the
       value of the --bind-address option. This enables the address
       to be accessed at runtime. (Bug #44355, Bug #11752999)

     * "Unknown table" error messages that included only the table
       name now include the database name as well. (Bug #34750, Bug
       #11747993)

     * Previously, EXPLAIN output for a large union truncated the
       UNION RESULT row at the end of the list as follows if the
       string became too large:
        <union1,2,3,4,...>
       To make it easier to understand the union boundaries,
       truncation now occurs in the middle of the string:
        <union1,2,3,...,9>
       (Bug #30597, Bug #11747073)

     * The OpenGIS specification defines functions that test the
       relationship between two geometry values. MySQL originally
       implemented these functions such that they used object
       bounding rectangles and returned the same result as the
       corresponding MBR-based functions. Corresponding versions are
       now available that use precise object shapes. These versions
       are named with an ST_ prefix. For example, Contains() uses
       object bounding rectangles, whereas ST_Contains() uses object
       shapes. For more information, see Section 11.17.5.4.2,
       "Functions That Test Spatial Relationships Between
       Geometries."
       There are also now ST_ aliases for existing spatial functions
       that were already exact. For example, ST_IsEmpty() is an alias
       for IsEmpty() (Bug #4249, Bug #11744883)

     * TO_BASE64() and FROM_BASE64() functions are now available to
       perform encoding to and from base-64 strings.

     * The Block Nested-Loop (BNL) Join algorithm previously used
       only for inner joins has been extended and can be employed for
       outer join operations, including nested outer joins. For more
       information, see Section 7.13.11, "Block Nested-Loop Joins."
       In conjunction with this work, there is a new system variable,
       optimizer_join_cache_level, that controls how join buffering
       is done.

     * A --bind-address option has been added to a number of MySQL
       client programs: mysql, mysqldump, mysqladmin, mysqlbinlog,
       mysqlcheck, mysqlimport, and mysqlshow. This is for use on a
       computer having multiple network interfaces, and enables you
       to choose which interface is used to connect to the MySQL
       server.


   Bugs fixed:
      The list of bugs fixed will follow in a separate mail, because
      of size restrictions on the mailing lists.

Hery Ramilison
MySQL/ORACLE Release Engineering Team



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql?unsub=arch...@jab.org

Reply via email to