MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Joerg Bruehe Date:December 11 2012 9:48pm
Subject:MySQL Community Server 5.6.9-rc has been released
View as plain text  
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

For information on installing MySQL 5.6.9 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 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

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

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

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

The list of all "Bugs Fixed" for 5.6.9 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 and migration tools so
businesses can achieve the highest levels of MySQL performance,
security and uptime.


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
         The gtid_lost server system variable has been renamed
         gtid_purged; in addition, this variable is no longer

       + The SQL_THREAD_WAIT_AFTER_GTIDS() function has been
    For more information, see Replication with Global Transaction
    ), and Global Transaction ID Options and Variables
    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

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
    ). This enhancement primarily affects read operations for BLOB
    columns in compressed
    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.
         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
    ) 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
    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
    ine_ddl) operation that copies the table, the secondary index
    ondary_index) of the table could become corrupted. (Bug

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

    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

  * 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

  * 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,  joerg.bruehe@stripped
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

MySQL Community Server 5.6.9-rc has been releasedJoerg Bruehe11 Dec