MySQL 6.0.10 Alpha has been released!

Dear MySQL users,

MySQL 6.0.10-alpha, a new version of the MySQL database system has been
released. The main page for MySQL 6.0 release is at

http://www.mysql.com/mysql60/

MySQL 6.0 includes two new storage engines: the transactional Falcon
engine, and the crash-safe Maria engine.

If you are using the Falcon storage engine in MySQL 6.0.9-alpha, you are
encouraged to wait for the MySQL 6.0.11-alpha before upgrading. Live
upgrade is not recommended for 6.0 alpha releases. Users are strongly
encouraged to dump their database and reload them after the upgrade. If
you are new to the Falcon storage engine, we encourage you to either test
Falcon in MySQL 6.0.9-alpha or wait for MySQL 6.0.11-alpha.

The 6.0.10 release contains a large number of bug fixes for Falcon. After
6.0.10-alpha was built several bugs were reported and fixed, and will be
part of the MySQL 6.0.11-alpha release.

If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at

http://www.mysql.com/why-mysql/white-papers/falcon-getting-s tarted.php

and the Falcon White Paper at

http://www.mysql.com/why-mysql/white-papers/storage-engines- falcon.php

The Maria storage engine is a crash-safe version of MyISAM. Maria
supports all of the main functionality of the MyISAM engine, plus recovery
support (in the event of a system crash), all MyISAM row formats and a new
Maria-specific row format. Maria is documented at

http://dev.mysql.com/doc/refman/6.0/en/se-maria.html

MySQL 6.0.10-alpha is available in source and binary form for a number of
platforms from our download pages at

http://dev.mysql.com/downloads/mysql/6.0.html

and mirror sites. Note that 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, and
patches at

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

The following section lists functionality which has been added or changed,
as well as security-related, incompatible and important bugs fixes since
the previous version of MySQL 6.0. The full changelog including many
other changes can be viewed online at

http://dev.mysql.com/doc/refman/6.0/en/news-6-0-10.html

Enjoy!

Jonathan Perkin
The MySQL Build Team, Sun Microsystems

============================================================ ==================

Functionality added or changed:

* Important Change: Replication: RESET MASTER and RESET SLAVE
now reset the values shown for Last_IO_Error, Last_IO_Errno,
Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE
STATUS. (Bug#34654: http://bugs.mysql.com/34654)

* Replication: A new global server variable sync_relay_log is
introduced for use on replication slaves. Setting this
variable to a nonzero integer value N causes the slave to
synchonize the relay log to disk after every N events. It is
analogous to how the sync_binlog variable works for binary
logs on a replication master.
This variable can also be set in my.cnf using the server
option --sync-relay-log.
For more information, see Section 16.1.3.3, "Replication Slave
Options and Variables."
(Bug#31665: http://bugs.mysql.com/31665,
Bug#35542: http://bugs.mysql.com/35542,
Bug#40337: http://bugs.mysql.com/40337)

* Replication: In circular replication, it was sometimes
possible for an event to propagate such that it would be
reapplied on all servers. This could occur when the
originating server was removed from the replication circle and
so could no longer act as the terminator of its own events, as
normally happens in circular replication.
In order to prevent this from occurring, a new
IGNORE_SERVER_IDS option is introduced for the CHANGE MASTER
TO statement. This option takes a list of replication server
IDs; events having a server ID which appears in this list are
ignored and not applied. For more information, see Section
12.6.2.1, "CHANGE MASTER TO Syntax."
(Bug#25998: http://bugs.mysql.com/25998)
See also Bug#27808: http://bugs.mysql.com/27808.

* The libedit library was upgraded to version 2.11.
(Bug#42433: http://bugs.mysql.com/42433)

* A new status variable, Queries, indicates the number of
statements executed by the server. This includes statements
executed within stored programs, unlike the Questions variable
which includes only statements sent to the server by clients.
(Bug#41131: http://bugs.mysql.com/41131)

* Columns that provide a catalog value in INFORMATION_SCHEMA
tables (for example, TABLES.TABLE_CATALOG) now have a value of
def rather than NULL. (Bug#35427: http://bugs.mysql.com/35427)

* mysql-test-run.pl now supports --client-bindir and
--client-libdir options for specifying the directory where
client binaries and libraries are located.
(Bug#34995: http://bugs.mysql.com/34995)

Bugs fixed:

* Security Fix: Using an XPath expression employing a scalar
expression as a FilterExpr
(http://www.w3.org/TR/xpath#NT-FilterExpr) with ExtractValue()
or UpdateXML() caused the server to crash. Such expressions
now cause an error instead.
(Bug#42495: http://bugs.mysql.com/42495)

* Incompatible Change: The fix for
Bug#33699: http://bugs.mysql.com/33699 introduced a change to
the UPDATE statement such that assigning NULL to a NOT NULL
column caused an error even when strict SQL mode was not
enabled. The original behavior before was that such
assignments caused an error only in strict SQL mode, and
otherwise set the column to the the implicit default value for
the column data type and generated a warning. (For information
about implicit default values, see Section 10.1.4, "Data Type
Default Values.")
The change caused compatibility problems for applications that
relied on the original behavior. It also caused replication
problems between servers that had the original behavior and
those that did not, for applications that assigned NULL to NOT
NULL columns in UPDATE statements without strict SQL mode
enabled. This change has been reverted so that UPDATE again
had the original behavior. Problems can still occur if you
replicate between servers that have the modified UPDATE
behavior and those that do not.
(Bug#39265: http://bugs.mysql.com/39265)

* Important Change: Replication: If a trigger was defined on an
InnoDB table and this trigger updated a non-transactional
table, changes performed on the InnoDB table were replicated
and were visible on the slave before they were committed on
the master, and were not rolled back on the slave after a
successful rollback of those changes on the master.
As a result of the fix for this issue, the semantics of mixing
non-transactional and transactional tables in a transaction in
the first statement of a transaction have changed. Previously,
if the first statement in a transaction contained
non-transactional changes, the statement was written directly
to the binary log. Now, any statement appearing after a BEGIN
(or immediately following a COMMIT if AUTOCOMMIT = 0) is
always considered part of the transaction and cached. This
means that non-transactional changes do not propagate to the
slave until the transaction is committed and thus written to
the binary log.
See Section 16.3.1.25, "Replication and Transactions," for
more information about this change in behavior.
(Bug#40116: http://bugs.mysql.com/40116)

* Important Change: Replication: MyISAM transactions replicated
to a transactional slave left the slave in an unstable
condition. This was due to the fact that, when replicating
from a non-transactional storage engine to a transactional
engine with AUTOCOMMIT turned off, no BEGIN and COMMIT
statements were written to the binary log; thus, on the slave,
a never-ending transaction was started.
The fix for this issue includes enforcing AUTOCOMMIT mode on
the slave by replicating all AUTOCOMMIT=1 statements from the
master. (Bug#29288: http://bugs.mysql.com/29288)

--
Jonathan Perkin, Product Engineering, MySQL
Database Technology Group, Sun Microsystems

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