MySQL Community Server 5.6.3 has been released (part 1)

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-previo us-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


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org