MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Hery Ramilison Date:October 3 2011 8:10pm
Subject:MySQL Community Server 5.6.3 has been released (part 1)
View as plain text  
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

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

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

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

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

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

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.


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

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, "Writing Audit

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

   * 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, "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, "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, "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, "Non-Recursive Deadlock

   * 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, "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
     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.
      results in
      /* select#1 */ select 36 from dual
      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:
     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:
     (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_KEY options for specifying other SSL
     (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
     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, "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

MySQL Community Server 5.6.3 has been released (part 1)Hery Ramilison3 Oct