MySQL Community Server 5.6.9-rc has been released

[Joerg Bruehe]

Dear MySQL users,

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

The new features in this release are of Release Candidate 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.9 includes all features in MySQL 5.5 and previous 5.6
Development Milestone Releases. An overview of what's new in MySQL 5.6
is available online at

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

For information on installing MySQL 5.6.9 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 MySQL 5.6.9 RC or other
pre-production releases to a previous release series is not supported.

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

Please note that the list of platforms for MySQL 5.6 has been adapted to
the changes in the field:
- Apple Mac OS X 10.6 and 10.7 on x86 (32 bit) and x86_64
(Binary packages of MySQL 5.6 are not provided for OS X 10.5),
- Debian 6 on x86 (32 bit) and x86_64
(Binary packages of MySQL 5.6 are not provided for Debian 5),
- RedHat Enterprise / Oracle Linux 5 and 6 on x86 (32 bit) and x86_64
(Binary packages of MySQL 5.6 are not provided for RHEL/OL 4),
- SuSE Enterprise Linux 11 on x86_64
(Binary packages of MySQL 5.6 are not provided for SLES 10),
- generic Linux (kernel 2.6) on x86 (32 bit) and x86_64,
using glibc 2.5 (or newer),
- FreeBSD 9 on x86_64
(Binary packages of MySQL 5.6 are not provided for FreeBSD 7 and 8),
- Oracle Solaris 10 and 11 on Sparc (64 bit), x86 (32 bit) and x86_64,
- Windows Vista, 7, and 2008 on x86 (32 bit) and x86_64
(Binary packages of MySQL 5.6 are not provided for Windows XP and
2003).

This does not affect the list of supported platforms for 5.1 and 5.5.

For Linux, the dependency on glibc 2.5 is new with 5.6.9, it is
reflected in the names of the binary packages for generic Linux:
"linux-glibc2.5" (former: "linux2.6").
All supported specific platforms (RedHat 5 and newer, SuSE 11, ...) are
using glibc 2.5 or newer.
If you want to check your system, you may simply "run" the library:
| Prompt$ /lib/libc.so.6
| GNU C Library stable release version 2.7, by Roland McGrath et al.
| Copyright (C) 2007 Free Software Foundation, Inc.
| ...
The above example was done on Debian 6, it shows glibc 2.7.

Packages for specific Linux distributions are provided in the specific
format (RPM or deb), in addition the generic tar.gz packages will fit
these distributions.
For RedHat-alike distributions like CentOS or Fedora, both the RedHat
and the generic packages should work.
If you are using a newer version of your operating system, its binary
compatibility approach (supporting applications built for older
versions) should ensure you can use MySQL 5.6.

Windows packages are now available via the new Installer for Windows
Installer or .ZIP (no-install) packages for more advanced needs. It
should be noted that the previous MSI packaging is no longer available
and the point and click configuration wizards and all MySQL products
are now available in the unified Installer for Windows:

http://dev.mysql.com/downloads/installer/

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

http://bugs.mysql.com/report.php

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

http://dev.mysql.com/doc/refman/5.6/en/news-5-6-9.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 and migration tools so
businesses can achieve the highest levels of MySQL performance,
security and uptime.

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

Enjoy!


On behalf of the MySQL Build Team at Oracle,

Jörg Brühe


=========


Changes in MySQL 5.6.9 (2012-Dec-11)

Installation Notes

* The --random-passwords option for mysql_install_db is now
used for MySQL install operations (not upgrades) which are
done using Solaris PKG packages.

Functionality Added or Changed

* Incompatible Change: Replication: A number of variable and
other names relating to GTID-based replication have been
changed, with a view to making these names more appropriate
and meaningful. The old names are no longer supported.
The features so renamed are shown in the following list:

+ The --disable-gtid-unsafe-statements server option has
been renamed --enforce-gtid-consistency; the
disable_gtid_unsafe_statements system variable has been
renamed enforce_gtid_consistency.

+ The gtid_done server system variable has been renamed
gtid_executed.
The gtid_lost server system variable has been renamed
gtid_purged; in addition, this variable is no longer
read-only.

+ The SQL_THREAD_WAIT_AFTER_GTIDS() function has been
renamed WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS().
For more information, see Replication with Global Transaction
Identifiers
(http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
), and Global Transaction ID Options and Variables
(http://dev.mysql.com/doc/refman/5.6/en/replication-options-gt
ids.html). (Bug #14775984)

* Windows Vista, Windows Server 2008, and newer support native
symlinking using the mklink command. This makes the MySQL
Server implementation of database symbolic links using .sym
files redundant, so that mechanism is now deprecated and will
be removed in a future MySQL release. See Using Symbolic Links
for Databases on Windows
(http://dev.mysql.com/doc/refman/5.6/en/symbolic-links.html#wi
ndows-symbolic-links).

Bugs Fixed

* Performance: InnoDB: The timing values for low-level InnoDB
read operations were adjusted for better performance with fast
storage devices, such as SSD
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_ssd
). This enhancement primarily affects read operations for BLOB
columns in compressed
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_com
pression) tables. (Bug #13702112, Bug #64258)

* Incompatible Change: The THREAD_ID column in Performance
Schema tables was widened from INT to BIGINT to accommodate
64-bit values.
If you upgrade to this release of MySQL from an earlier
version, you must run mysql_upgrade (and restart the server)
to incorporate this change to the performance_schema database.
(Bug #14664453)

* Incompatible Change: Connection ID (thread ID) values greater
than 32 bits can occur on some systems (such as busy or
long-running 64-bit systems), causing these problems:

+ Connection IDs written to the general query log and slow
query log were incorrect. This was true for logging to
both files and tables.

+ The CONNECTION_ID() function could return a value with a
data type too small for values larger than 32 bits.

+ The mysql_thread_id() and mysql_kill() C API functions
did not handle ID values larger than 32 bits. This could
result in killing the wrong thread; for example, if you
invoked mysql_kill(mysql_thread_id()).

Connection IDs now are permitted to be 64-bit values when the
server supports them (when built with 64-bit data types),
which has these effects:

+ Connection IDs are logged correctly to the general query
log and slow query log.
Note
This change involves a modification to the log tables, so
after upgrading to this release, you must run
mysql_upgrade and restart the server.

+ CONNECTION_ID() returns a data type appropriate for
values larger than 32 bits.

+ mysql_thread_id() is unchanged; the client/server
protocal has only 4 bytes for the ID value. This function
returns an incorrect (truncated) value for connection IDs
larger than 32 bits and should be avoided.
mysql_kill() still cannot handle values larger than 32
bits, but to guard against killing the wrong thread now
returns an error in these cases:
o If given an ID larger than 32 bits, mysql_kill()
returns a CR_INVALID_CONN_HANDLE error.
o After the server's internal thread ID counter
reaches a value larger than 32 bits, it returns an
ER_DATA_OUT_OF_RANGE error for any mysql_kill()
invocation and mysql_kill() fails.
To avoid problems with mysql_thread_id() and
mysql_kill(), do not use them. To get the connection ID,
execute a SELECT CONNECTION_ID() query and retrieve the
result. To kill a thread, execute a KILL statement.
(Bug #19806, Bug #11745768, Bug #65715, Bug #14236124, Bug
#44728, Bug #11753308)

* Important Change: InnoDB: A DML
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dml
) statement using the index merge access method could lock
many rows from the table, even when those rows were not part
of the final result set. This fix reduces the excessive
locking
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_loc
king) by releasing the locks of unmatched rows. This
optimization affects only transactions with isolation level
equal to or less strict than READ COMMITTED; it does not apply
to transactions using REPEATABLE READ or SERIALIZABLE
isolation level. (Bug #14226171)

* Important Change: Replication: Because running the server with
GTIDs enabled prevented changes to nontransactional tables,
programs such as mysql_upgrade and mysql_install_db were
unable to operate on system tables that used the MyISAM
storage engine and therefore could not function correctly.
Now, when running with --enforce-gtid-consistency (required
whenever --gtid-mode=ON), the server allows single statements
on nontransactional tables. (Bug #14722659)

* Important Change: Replication: Formerly, the value of the
Seconds_Behind_Master column in the output of SHOW SLAVE
STATUS was always set to NULL whenever the SQL thread or the
I/O thread was stopped. Now, this column is set to NULL only
if the SQL thread is not running, or if the I/O thread is not
running following a check to determine whether or not the SQL
thread has processed all of the relay log. (If the SQL thread
has finished processing and the I/O thread is running,
Seconds_Behind_Master is 0.) (Bug #12946333)

* Partitioning: InnoDB: Previously, when attempting to optimize
one or more partitions of a partitioned table that used a
storage engine that does not support partition-level OPTIMIZE,
such as InnoDB, MySQL reported Table does not support
optimize, doing recreate + analyze instead, then re-created
the entire table, but did not actually analyze it. Now in such
cases, the warning message is, Table does not support optimize
on partitions. All partitions will be rebuilt and analyzed. In
addition, the entire table is analyzed after first being
rebuilt. (Bug #11751825)

* InnoDB: An online DDL operation for an InnoDB table
incorrectly reported an empty value ('') instead of the
correct key value when it reported a duplicate key error for a
unique index using an index prefix. (Bug #14729221)

* InnoDB: InnoDB tables with FULLTEXT indexes could allocate
memory for thread handles that was never released, possibly
leading to resource issues on Windows systems. (Bug #14759163)

* InnoDB: During an online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_onl
ine_ddl) operation that copies the table, the secondary index
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_sec
ondary_index) of the table could become corrupted. (Bug
#14753701)

* InnoDB: If an ALTER TABLE statement failed while attempting to
create a FULLTEXT index for an InnoDB table, the server could
halt with an assertion error while dropping the incomplete
index. (Bug #14504174)

* Replication: If a table to be replicated had a FULLTEXT index,
this index was not ruled out when selecting the type of scan
to be used in finding the next row, even though it cannot be
used to find the correct one. The row applier subsequently
tried unsuccessfully to employ an index scan, causing
replication to fail. Now in such cases, indexes which do not
provide for sequential access (such as FULLTEXT) are not
considered when determining whether to use a table, index, or
hash scan for this purpose. (Bug #14843764)

* Replication: When using the GTID-aware master-slave protocol,
the slave I/O thread used the wrong position. When using
GTIDs, the position is not normally used, but as a special
case, the position was used in addition to the GTID when the
slave reconnected to the same master (even though this was not
necessary). This problem is fixed by making the GTID-aware
master-slave protocol not use positions at all any longer.
(Bug #14828028)

* Replication: Given a stored routine R in which the
GTID_SUBTRACT() function was invoked: Once GTID_SUBTRACT()
returned NULL when called inside R, it continued to return
NULL every time it was called within R, for the remainder of
the client session. (Bug #14838575)

* Replication: MySQL Enterprise Backup, mysqldump, and
mysqlhotcopy could not be used with a GTID-enabled MySQL
Server, because they were unable to restore the server's GTID
state and so could not restore from any point in the binary
log other than the very beginning.
As part of the fix for this problem, the gtid_purged system
variable (formerly named gtid_lost) is no longer read-only;
now it is possible to add GTIDs to it when gtid_executed
(formerly gtid_done) is empty. (Bug #14787808)

* Replication: Restarting replication after the first binary log
file was purged resulted in the error Got fatal error 1236
from master when reading data from binary log: 'The slave is
connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1,
but the master has purged binary logs containing GTIDs that
the slave requires.' This led GTID-based replication to fail.
(Bug #14756691)

* Invalid memory reads could occur for queries that selected
from a zero-length table name. (Bug #14780820)

* With LOCK TABLES in effect, CREATE TABLE IF NOT EXISTS ...
LIKE could raise an assertion. (Bug #14788976)

* An assertion was raised if ALTER TABLE was used to rename a
column to same name as an existing column while also
reordering the renamed column using AFTER or FIRST. (Bug
#14756089)

* An assertion could be raised if semi-join materialization was
used to evaluate a NOT IN subquery. (Bug #14751858)

* For some continuation handler nestings, continuation could
occur at the wrong location. (Bug #14724836)

* SHOW PROCESSLIST output was not sorted in Id order. (Bug
#14771006)

* For UPDATE statements, EXPLAIN showed the total key length in
the key_len column rather than the length of the used key
parts. (Bug #14682438)

* Starting the server with --bind-address and then setting
host_cache_size to 0 could result in the server stopping for
certain kinds of client connections. (Bug #14689561)

* With index condition pushdown enabled, the optimizer could
produce incorrect results for derived tables. (Bug #14640176)

* The optimizer could incorrectly use a nonspatial index to
optimize spatial operations, causing an assertion to be
raised. (Bug #14600994)

* CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had
a corrupt key (.MYI) file. Now the server produces an error.
(Bug #13556441)

* CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had
a corrupt key (.MYI) file. Now the server produces an error.
(Bug #13556107, Bug #13556000)

* For dumps of the mysql database, mysqldump skipped the event
table unless the --events option was given. To skip this table
if that is desired, use the --ignore-table option instead (Bug
#55587, Bug #11762933)

* mysqld_safe ignored the value of the UMASK environment
variable, leading to behavior different from mysqld with
respect to the access mode of created files. Now mysqld_safe
(and mysqld_multi) attempt to approximate the same behavior as
mysqld. (Bug #57406, Bug #11764559)

* LAST_INSERT_ID(expr) did not work for expr values greater than
the largest signed BIGINT value. (Bug #20964, Bug #11745891)

--
Joerg Bruehe, MySQL Build Team, [e-mail]
ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz Amtsgericht Muenchen: HRA 95603
Komplementaerin: ORACLE Deutschland Verwaltung B.V. Utrecht, Niederlande
Geschaeftsfuehrer: Alexander van der Ven, Astrid Kepper, Val Maher