MySQL Community Server 5.6.3 has been released (part 1) (no replies)

Dear MySQL users,

MySQL Server 5.6.3 (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.3 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.3 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.3 may also be viewed online at

     http://dev.mysql.com/doc/refman/5.6/en/news-5-6-3.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/

Enjoy!

Changes in MySQL 5.6.3 (03 October 2011)

Parallel Event Execution (multi-threaded slave)

  * Replication: MySQL replication now supports a multi-threaded
    slave executing replication events from the master across
    different databases in parallel, which can result in
    significant improvements in application throughput when
    certain conditions are met. The optimum case is that the data
    be partitioned per database, and that updates within a given
    database occur in the same order relative to one another as
    they do on the master. However, transactions do not need to be
    coordinated between different databases.
    The slave_parallel_workers server system variable (added in
    this release) sets the number of slave worker threads for
    executing replication events in parallel. When parallel
    execution is enabled, the slave SQL thread acts as the
    coordinator for the slave worker threads, among which
    transactions are distributed on a per-database basis. This
    means that a worker thread on the slave slave can process
    successive transactions on a given database without waiting
    for updates on other databases to complete.
    Due to the fact that transactions on different databases can
    occur in a different order on the slave than on the master,
    checking for the most recently executed transaction does not
    guarantee that all previous transactions from the master have
    been executed on the slave. This has implications for logging
    and recovery when using a multi-threaded slave. For
    information about how to interpret binary logging information
    when using multi-threading on the slave, see Section
    12.4.5.35, "SHOW SLAVE STATUS Syntax."

Optimizer Features

  * These query optimizer improvements were implemented:

       + The EXPLAIN statement now provides execution plan
         information for DELETE, INSERT, REPLACE, and UPDATE
         statements. Previously, EXPLAIN provided information only
         about SELECT statements.

       + The optimizer more efficiently handles subqueries in the
         FROM clause (that is, derived tables):
            o Materialization of subqueries in the FROM clause is
              postponed until their contents are needed during
              query execution, which improves performance.
              Previously, subqueries in the FROM clause were
              materialized for EXPLAIN SELECT statements. This
              resulted in partial SELECT execution, even though
              the purpose of EXPLAIN, is to obtain query plan
              information, not to execute the query. The
              materialization no longer occurs, so EXPLAIN is
              faster for such queries. For non-EXPLAIN queries,
              delay of materialization may result in not having to
              do it at all. Consider a query that joins the result
              of a subquery in the FROM clause to another table.
              If the optimizer processes that other table first
              and finds that it returns no rows, the join need not
              be carried out further and the optimizer can
              completely skip materializing the subquery.
            o During query execution, the optimizer may add an
              index to a derived table to speed up row retrieval
              from it.
         For more information, see Section 7.13.15.2, "Optimizing
         Subqueries in the FROM Clause."

       + A Batched Key Access (BKA) Join algorithm is now
         available that uses both index access to the joined table
         and a join buffer. The BKA algorithm supports inner join
         and outer join operations, including nested outer joins.
         Benefits of BKA include improved join performance due to
         more efficient table scanning.
         Two flags have been added to the optimizer_switch system
         variable (block_nested_loop and batched_key_access).
         These flags control how the optimizer uses the Block
         Nested-Loop and Batched Key Access join algorithms.
         Previously, the optimizer_join_cache_level system
         variable was used for join buffer control; this variable
         has been removed.
         For more information, see Section 7.13.11, "Block
         Nested-Loop and Batched Key Access Joins."

       + A tracing capability has been added to the optimizer.
         This will be of use to optimizer developers, and also to
         users who file bugs against the optimizer and want to
         provide more information that will help resolve the bug.
         The interface is provided by a set of optimizer_trace_xxx
         system variables and the
         INFORMATION_SCHEMA.OPTIMIZER_TRACE table, but is subject
         to change. For details, see MySQL Internals: Optimizer
         tracing
         (http://forge.mysql.com/wiki/MySQL_Internals_Optimizer_tr
         acing).
    (Bug #44802, Bug #11753371)

Performance Schema Notes

  * The Performance Schema has these additions:

       + The Performance Schema now instruments stages and
         statements. Stages are steps during the
         statement-execution process, such as parsing a statement,
         opening a table, or performing a filesort operation.
         Stages correspond to the thread states displayed by SHOW
         PROCESSLIST or that are visible in the
         INFORMATION_SCHEMA.PROCESSLIST table. Stages begin and
         end when state values change.
         Within the event hierarchy, wait events nest within stage
         events, which nest within statement events. To reflect
         this nesting in wait-event tables such as
         events_waits_current, the NESTING_EVENT_ID column now can
         be non-NULL to indicate the EVENT_ID value of the event
         within which an event is nested, and NESTING_EVENT_TYPE
         is a new column indicating the type of the nesting event.
         The setup_instruments table now contains instruments with
         names that begin with stage and statement. Corresponding
         to these instruments, the setup_timers table now contains
         rows with NAME values of stage and statement that
         indicate the unit for stage and statement event timing.
         The default unit for each is NANOSECOND.
         These new tables store stage and statement events:
            o events_stages_current: Current stage events
            o events_stages_history: The most recent stage events
              for each thread
            o events_stages_history_long: The most recent stage
              events overall
            o events_statements_current: Current statement events
            o events_statements_history: The most recent statement
              events for each thread
            o events_statements_history_long: The most recent
              statement events overall
         The setup_consumers table now contains consumer values
         with names corresponding to those table names. These
         consumers may be used to filter collection of stage and
         statement events.
         There are also summary tables that provide aggregated
         stage and statement information.
         Application developers can use statement instrumentation
         to see in detail the statements generated by an
         application, and how these statements are executed by the
         server. Stage instrumentation can be used to focus on
         particular parts of statements. This information may be
         useful to change how an application issues queries
         against the database, to minimize the application
         footprint on the server, and to improve application
         performance and scalability.

       + The Performance Schema now provides statistics about
         connections to the server. When a client connects, it
         does so under a particular user name and from a
         particular host. The Performance Schema tracks
         connections per account (user name plus host name) and
         separately per user name and per host name, using these
         tables:
            o accounts: Connection statistics per client account
            o hosts: Connection statistics per client host name
            o users: Connection statistics per client user name
         There are also summary tables that provide aggregated
         connection information.
         It is good security practice to define a dedicated
         account per application, so that an application is given
         privileges to perform only those actions that it needs
         during its operation. This also facilitates monitoring
         because the information in the connection tables can be
         used by application developers to see load statistics per
         application when deploying several applications against a
         given database server.

       + Previously, the setup_objects table could be used only to
         include patterns specifying which objects to instrument.
         There was no way to explicitly disable object
         instrumentation, such as to configure instrumention for
         all tables except those in a particular database. Now the
         setup_objects table includes an ENABLED column that
         indicates whether to instrument matching objects. This
         feature improves the setup_objects table usability
         because it permits exclusion patterns.
         The default table contents now include a row that
         disables instrumentation for tables in the mysql
         database, which is a change from the previous default
         object instrumentation. This change is chosen assuming
         that end users want to instrument application objects,
         not internal server tables. The change reduces the
         default Performance Schema overhead because I/O and locks
         on mysql tables are not instrumented.
         The table also includes rows that disable instrumentation
         for tables in the INFORMATION_SCHEMA and
         performance_schema databases. This is not a change in
         behavior because those tables were not instrumented
         before. Rather, these rows make the full object
         instrumentation defaults explicit.

       + The Performance Schema now instruments sockets. This
         enables monitoring of network communication to and from
         the server. Information collected includes network
         activity such as socket instances, socket operations, and
         number of bytes transmitted and received.
         The setup_instruments table now contains instruments with
         names that begin with wait/io/socket. There is also an
         idle instrument used for idle events when a socket is
         waiting for the next request from the client.
         Corresponding to the latter instrument, the setup_timers
         table now contains a row with a NAME value of idle that
         indicates the unit for idle event timing. The default
         unit is MICROSECOND.
         These new tables contain socket information:
            o socket_instances: A real-time snapshot of the active
              connections to the MySQL server
            o socket_summary_by_instance: Aggregate timer and byte
              count statistics generated by the wait/io/socket/*
              instruments for all socket I/O operations, per
              socket instance
            o socket_summary_by_event_name: Aggregate timer and
              byte count statistics generated by the
              wait/io/socket/* instruments for all socket I/O
              operations, per socket instrument
         The information in the socket tables can be used by
         application developers, particularly those developing
         web-based applications, to assess the volume of network
         traffic directly attributable to queries generated by
         their application. This can be particularly useful during
         development of applications intended for large-scale
         implementations.
    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: In the audit plugin interface, the
    event_class member was removed from the mysql_event_general
    structure and the calling sequence for the notification
    function changed. Originally, the second argument was a
    pointer to the event structure. The function now receives this
    information as two arguments: an event class number and a
    pointer to the event. Corresponding to these changes,
    MYSQL_AUDIT_INTERFACE_VERSION was increased to 0x0300.
    The plugin_audit.h header file, and the NULL_AUDIT example
    plugin in the plugin/audit_null directory have been modified
    per these changes. See Section 21.2.4.8, "Writing Audit
    Plugins."

  * Important Change: Replication: The RESET SLAVE statement has
    been extended with an ALL keyword. In addition to deleting the
    master.info, relay-log.info, and all relay log files, RESET
    SLAVE ALL also clears all connection information otherwise
    held in memory following execution of RESET SLAVE. (Bug
    #11809016)

  * InnoDB Storage Engine: InnoDB now permits concurrent reads
    while creating a secondary index. (Bug #11853126)
    See also Bug #11751388, Bug #11784056, Bug #11815600.

  * InnoDB Storage Engine: The InnoDB redo log files now have a
    maximum combined size of 512GB, increased from 4GB. You can
    specify the larger values through the innodb_log_file_size
    option. (Bug #11765780, Bug #58779)

  * InnoDB Storage Engine: Improved concurrency for extending
    InnoDB tablespace files, which could prevent stalls on busy
    systems with many tables that use that innodb_file_per_table
    setting. (Bug #11763692, Bug #56433)

  * InnoDB Storage Engine: InnoDB tables can now be created with
    character sets whose collation ID is greater than 255. This
    capability opens up InnoDB tables for use with a range of
    user-defined character sets. MySQL's predefined character sets
    have previously been limited to a maximum of 255, and now that
    restriction is lifted. See Section 13.2.6.2, "Two-Byte
    Collation IDs for InnoDB Tables" for details.

  * InnoDB Storage Engine: You can improve the efficiency of the
    InnoDB checksum feature by enabling the innodb_use_crc32
    configuration option, which turns on a faster checksum
    algorithm. Data written using the old checksum algorithm is
    fully upward-compatible. Tablespaces updated under the new
    checksum algorithm are not downward-compatible with previous
    versions of MySQL. See Section 13.2.5.2.4, "Fast CRC32
    Checksum Algorithm" for details.

  * InnoDB Storage Engine: At shutdown, MySQL can record the pages
    that are cached in the InnoDB buffer pool, then reload those
    same pages upon restart. This technique can help to quickly
    reach consistent throughput after a restart, without a lengthy
    warmup period. This preload capability uses a compact save
    format and background I/O to minimize overhead on the MySQL
    server. The basic dump/restore capability is enabled through
    the configuration options innodb_buffer_pool_dump_at_shutdown
    and innodb_buffer_pool_load_at_startup. Related configuration
    options such as innodb_buffer_pool_dump_now and
    innodb_buffer_pool_load_now offer extra flexibility for
    advanced users to configure the MySQL server for different
    workloads. See Section 13.2.5.2.5, "Faster Restart by
    Preloading the InnoDB Buffer Pool" for details.

  * InnoDB Storage Engine: The code that detects deadlocks in
    InnoDB transactions has been modified to use a fixed-size work
    area rather than a recursive algorithm. The resulting
    detection operation is faster as a result. You do not need to
    do anything to take advantage of this enhancement. For
    details, see Section 13.2.5.2.3, "Non-Recursive Deadlock
    Detection."

  * InnoDB Storage Engine: The InnoDB thread-scheduling code has
    been enhanced to work better with greater than 16 threads.
    Where possible, atomic instructions are used. You control this
    feature by setting the configuration option
    innodb_thread_concurrency to a non-zero value, and adjusting
    the value of innodb_adaptive_max_sleep_delay.

  * InnoDB Storage Engine: Work continues to offload flush
    operations from the InnoDB main thread, doing them in the
    page_cleaner thread instead. The latest changes to the the
    buffer pool flushing algorithms can improve performance for
    some I/O-bound workloads, particularly in configurations with
    multiple buffer pool instances. You control this feature by
    adjusting the settings for the innodb_lru_scan_depth and
    innodb_flush_neighbors configuration options. To find the
    optimal settings, test each combination of the above settings
    with both the Adaptive Hash Index and the Doublewrite Buffer
    turned on and off. See Section 13.2.5.2.6, "Improvements to
    Buffer Pool Flushing" for more details.

  * InnoDB Storage Engine: This feature optionally moves the
    InnoDB undo log out of the system tablespace into one or more
    separate tablespaces. The I/O patterns for the undo log make
    these new tablespaces good candidates to move to SSD storage,
    while keeping the system tablespace on hard disk storage. This
    feature is controlled by the configuration options
    innodb_undo_directory, innodb_undo_tablespaces, and
    innodb_undo_logs (formerly known as innodb_rollback_segments).
    Users cannot drop the separate tablespaces created to hold
    InnoDB undo logs, or the individual segments inside those
    tablespaces.
    MySQL instances configured this way are not
    downward-compatible; older versions of MySQL cannot access the
    undo logs that reside in their own tablespace.

  * Replication: MySQL 5.6.1 added timestamps to the error
    messages shown in the Last_IO_Error and Last_SQL_Error columns
    of the output of SHOW SLAVE STATUS. Now these timestamps are
    shown in separate columns of their own, named
    Last_IO_Error_Timestamp and Last_SQL_Error_Timestamp,
    respectively. (Bug #11765599, Bug #58584)
    See also Bug #43535, Bug #11752361.

  * Following EXPLAIN EXTENDED, a change has been made to the
    transformed query displayed by SHOW WARNINGS. Each SELECT part
    now is preceded by the id value from the associated EXPLAIN
    output row. This makes it easier to see the correspondence
    between those rows and parts of the transformed query.
    Examples:
     EXPLAIN EXTENDED SELECT 36 FROM DUAL
     results in
     /* select#1 */ select 36 from dual
     EXPLAIN EXTENDED SELECT a FROM t
     WHERE a IN (SELECT b FROM u UNION SELECT c from v)
     results in
     /* select#1 */ select a from t where a in (/* select#2 */
     select b from u union /* select#3 */ select c from v);
    (Bug #13035597)

  * Several memory allocation calls were removed, resulting in
    improved performance. (Bug #12552221)

  * CMake configuration support on Linux now provides a boolean
    ENABLE_GCOV option to control whether to include support for
    gcov. (Bug #12549572)

  * Replication: BEGIN, COMMIT, and ROLLBACK statements are now
    cached along with the statements instead of being written when
    the cache is flushed to the binary log. This change does not
    affect DDL statements---which are written into the statement
    cache, then immediately flushed---or Incident events (which,
    along with Rotate events, are still written directly to the
    binary log).
    See also Bug #57275, Bug #11764443.

  * Previously, Performance Schema instrumentation for both the
    binary log and the relay log used these instruments:
     wait/io/file/sql/binlog
     wait/io/file/sql/binlog_index
     wait/synch/mutex/sql/MYSQL_BIN_LOG::LOCK_index
     wait/synch/cond/sql/MYSQL_BIN_LOG::update_cond
    Now instrumentation for the relay log uses these instruments,
    which makes it possible to distinguish events for the binary
    log from those for the relay log:
     wait/io/file/sql/relaylog
     wait/io/file/sql/relaylog_index
     wait/synch/mutex/sql/MYSQL_RELAY_LOG::LOCK_index
     wait/synch/cond/sql/MYSQL_RELAY_LOG::update_cond
    (Bug #59658, Bug #11766528)

  * A new server option, --plugin-load-add, complements the
    --plugin-load option. --plugin-load-add adds a plugin or
    plugins to the set of plugins to be loaded at startup. The
    argument format is the same as for --plugin-load.
    --plugin-load-add can be used to avoid specifying a large set
    of plugins as a single long unwieldy --plugin-load argument.
    --plugin-load-add can be given in the absence of
    --plugin-load, but any instance of --plugin-load-add that
    appears before --plugin-load. has no effect because
    --plugin-load resets the set of plugins to load.
    This change affects the output of mysqld --verbose --help in
    that a value for plugin-load is no longer printed. (Bug
    #59026, Bug #11766001)

  * When invoked with the --auto-generate-sql option, mysqlslap
    dropped the schema specified with the --create-schema option
    at the end of the test run, which may have been unexpected by
    the user. mysqlslap no longer drops the schema, but has a new
    --create-and-drop-schema option that both creates and drops a
    schema. (Bug #58090, Bug #11765157)

  * The server now exposes SSL certificate expiration dates
    through the Ssl_server_not_before and Ssl_server_not_after
    status variables. Both variables have values in ANSI time
    format (for example, Sep 12 16:22:06 2013 GMT), or are blank
    for non-SSL connections. (Bug #57648, Bug #11764778)

  * Previously, TEMPORARY tables created with CREATE TEMPORARY
    TABLES had the default storage engine unless the definition
    included an explicit ENGINE option. (The default engine is the
    value of the default_storage_engine system variable.) Since
    MySQL 5.5.5, when the default storage engine was changed from
    the nontransactional MyISAM engine to the transactional InnoDB
    engine, TEMPORARY tables have incurred the overhead of
    transactional processing.
    To permit the default storage engine for TEMPORARY tables to
    be set independently of the default engine for permanent
    tables, the server now supports a default_tmp_storage_engine
    system variable. For example, to create TEMPORARY tables as
    nontransactional tables by default, start the server with
    --default_tmp_storage_engine=MyISAM. The storage engine for
    TEMPORARY tables can still be specified on an individual basis
    by including an ENGINE option in table definitions. (Bug
    #49232, Bug #11757216)

  * Previously, for MySQL binaries linked against OpenSSL, if an
    SSL key file supplied to the MySQL server or a MySQL client
    program (using the --ssl-key option) was protected by a
    passphrase, the program would prompt the user for the
    passphrase. This is now also the case for MySQL binaries
    linked against yaSSL. (Bug #44559, Bug #11753167)

  * The mysql client program now has a --binary-mode option that
    helps when processing mysqlbinlog output that may contain BLOB
    values. By default, mysql translates \r\n in statement strings
    to \n and interprets \0 as the statement terminator.
    --binary-mode disables both features. It also disables all
    mysql commands except charset and delimiter in non-interactive
    mode (for input piped to mysql or loaded using the source
    command). (Bug #33048, Bug #11747577)

  * MySQL binaries linked against OpenSSL (but not yaSSL) now
    support certificate revocation lists for SSL connections:

       + The MySQL server and MySQL client programs that support
         SSL recognize --ssl-crl and --ssl-crlpath options for
         specifying a revocation list file or directory containing
         such files.

       + The ssl_crl and ssl_crlpath system variables indicate the
         values of the --ssl-crl and --ssl-crlpath options with
         which the server was started.

       + The CHANGE MASTER TO statement has MASTER_SSL_CRL and
         MASTER_SSL_CRLPATH options for specifying revocation list
         information to use when the slave connects to the master.
         The mysql.slave_master_info file has two more rows to
         store the values of these options. The SHOW SLAVE STATUS
         statement has has two more columns to display the values
         of these options.
         The mysql_options() C API function has MYSQL_OPT_SSL_CRL
         and MYSQL_OPT_SSL_CRLPATH options for specifying
         revocation list information to use when the client
         connects to the master. In addition, mysql_options() now
         also supports MYSQL_OPT_SSL_CA, MYSQL_OPT_SSL_CAPATH,
         MYSQL_OPT_SSL_CERT, MYSQL_OPT_SSL_CIPHER, and
         MYSQL_OPT_SSL_KEY options for specifying other SSL
         parameters.
    (Bug #31224, Bug #11747191)

  * For temporary tables created with the CREATE TEMPORARY TABLE
    statement, the privilege model has changed.
    Previously, the CREATE TEMPORARY TABLES privilege enabled
    users to create temporary tables with the CREATE TEMPORARY
    TABLE statement. However, other operations on a temporary
    table, such as INSERT, UPDATE, or SELECT, required additional
    privileges for those operations for the database containing
    the temporary table, or for the nontemporary table of the same
    name.
    To keep privileges for temporary and nontemporary tables
    separate, a common workaround for this situation was to create
    a database dedicated to the use of temporary tables. Then for
    that database, a user could be granted the CREATE TEMPORARY
    TABLES privilege, along with any other privileges required for
    temporary table operations done by that user.
    Now, the CREATE TEMPORARY TABLES privilege enables users to
    create temporary tables with CREATE TEMPORARY TABLE, as
    before. However, after a session has created a temporary
    table, the server performs no further privilege checks on the
    table. The creating session can perform any operation on the
    table, such as DROP TABLE, INSERT, UPDATE, or SELECT.
    One implication of this change is that a session can
    manipulate its temporary tables even if the current user has
    no privilege to create them. Suppose that the current user
    does not have the CREATE TEMPORARY TABLES privilege but is
    able to execute a DEFINER-context stored procedure that
    executes with the privileges of a user who does have CREATE
    TEMPORARY TABLES and that creates a temporary table. While the
    procedure executes, the session uses the privileges of the
    defining user. After the procedure returns, the effective
    privileges revert to those of the current user, which can
    still see the temporary table and perform any operation on it.
    (Bug #27480, Bug #11746602)

  * mysqld now has a --ignore-db-dir option that tells the server
    to ignore a given name for purposes of the SHOW DATABASES
    statement or INFORMATION_SCHEMA tables. For example, if a
    MySQL configuration locates the data directory at the root of
    a file system on Unix, the system might create a lost+found
    directory there that the server should ignore. Starting the
    server with --ignore-db-dir=lost+found causes that name not to
    be listed as a database.
    To specify more than one name, use this option multiple times,
    once for each name. Specifying the option with an empty value
    (that is, as --ignore-db-dir=) resets the directory list to
    the empty list.
    Instances of this option given at server startup are used to
    set the ignore_db_dirs system variable.
    In addition to directories named by --ignore-db-dir,
    directories having a name that begins with a period are
    ignored as well. (Bug #22615, Bug #11746029)

  * Client programs now display more information for SSL errors to
    aid in diagnosis and debugging of connection problems. (Bug
    #21287, Bug #11745920)

  * Statement logging has been modified so that passwords do not
    appear in plain text. Passwords in statements such as CREATE
    USER or GRANT are rewritten not to appear literally in
    statement text, for the general query log, slow query log, and
    binary log.
    Password rewriting can be suppressed for the general query log
    by starting the server with the --log-raw option. This option
    may be useful for diagnostic purposes, to see the exact text
    of statements as received by the server, but for security
    reasons is not recommended for production use.

  * A new utility, mysql_plugin, enables MySQL administrators to
    manage which plugins a MySQL server loads. It provides an
    alternative to manually specifying the --plugin-load option at
    server startup or using the INSTALL PLUGIN and UNINSTALL
    PLUGIN statements at runtime. See Section 4.4.5, "mysql_plugin
    --- Configure MySQL Server Plugins."

  * The following items are deprecated and will be removed in a
    future MySQL release. Where alternatives are shown,
    applications should be updated to use them.

       + The innodb_table_monitor table. Similar information can
         be obtained from InnoDB INFORMATION_SCHEMA tables. See
         Section 18.30, "INFORMATION_SCHEMA Tables for InnoDB."

       + The innodb_locks_unsafe_for_binlog system variable.

       + The innodb_stats_sample_pages system variable. Use
         innodb_stats_transient_sample_pages instead.

       + The innodb_use_sys_malloc and The
         innodb_additional_mem_pool_size system variables.

  * The undocumented --all option for perror has been removed.
    Also, perror no longer displays messages for BDB error codes.

  * MySQL now includes support for manipulating IPv6 network
    addresses and for validating IPv4 and IPv6 addresses:

       + The INET6_ATON() and INET6_NTOA() functions convert
         between string and numeric forms of IPv6 addresses.
         Because numeric-format IPv6 addresses require more bytes
         than the largest integer type, the representation uses
         the VARBINARY data type.

       + The IS_IPV4() and IS_IPV6() functions test whether a
         string value represents a valid IPv4 or IPv6 address. The
         IS_IPV4_COMPAT() and IS_IPV4_MAPPED() functions test
         whether a numeric-format value represents a valid
         IPv4-compatible or IPv4-mapped address.

       + No changes were made to the INET_ATON() or INET_NTOA()
         functions that manipulate IPv4 addresses.
    IS_IPV4() is more strict than INET_ATON() about what
    constitutes a valid IPv4 address, so it may be useful for
    applications that need to perform strong checks against
    invalid values. Alternatively, use INET6_ATON() to convert
    IPv4 addresses to internal form and check for a NULL result
    (which indicates an invalid address). INET6_ATON() is equally
    strong as IS_IPV4() about checking IPv4 addresses.

  * The Windows installer now creates an item in the MySQL menu
    named MySQL command line client - Unicode. This item invokes
    the mysql client with properties set to communicate through
    the console to the MySQL server using Unicode. It passes the
    --default-character-set=utf8 option to mysql and sets the font
    to the Lucida Console Unicode-compatible font.

  * The max_allowed_packet system variable now controls the
    maximum size of parameter values that can be sent with the
    mysql_stmt_send_long_data() C API function.

  * The NULL_AUDIT example plugin in the plugin/audit_null
    directory has been updated to count instances of events in the
    MYSQL_AUDIT_CONNECTION_CLASS event class. See Section
    21.2.4.8, "Writing Audit Plugins."

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