MySQL Community Server 5.5.33 has been released (no replies)

Dear MySQL users,

MySQL Server 5.5.33 is a new version of the 5.5 production release
of the world's most popular open source database. MySQL 5.5.33 is
recommended for use on production systems.

MySQL 5.5 includes several high-impact enhancements to improve the
performance and scalability of the MySQL Database, taking advantage of
the latest multi-CPU and multi-core hardware and operating systems. In
addition, with release 5.5, InnoDB is now the default storage engine for
the MySQL Database, delivering ACID transactions, referential integrity
and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

     - Significantly improved performance on Windows, with various
       Windows specific features and improvements
     - Higher availability, with new semi-synchronous replication and
       Replication Heartbeat
     - Improved usability, with Improved index and table partitioning,
       SIGNAL/RESIGNAL support and enhanced diagnostics, including a new
       Performance Schema monitoring capability.

For a more complete look at what's new in MySQL 5.5, please see the
following resources:

MySQL 5.5 is GA, Interview with Tomas Ulin:
http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html

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

Whitepaper: What's New in MySQL 5.5:
http://www.mysql.com/why-mysql/white-papers/whats-new-in-mysql-5-5/

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/

For information on installing MySQL 5.5.33 on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/5.5/en/installing.html

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:
http://dev.mysql.com/doc/refman/5.5/en/upgrading.html

MySQL Database 5.5.33 is available in source and binary form for a
number of platforms from our download pages at:
http://dev.mysql.com/downloads/mysql/

The following section lists the changes in the MySQL source code since
the previous released version of MySQL 5.5. It may also be viewed
online at:
http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-33.html

Enjoy!

Changes in MySQL 5.5.33 (2013-07-31)

Functionality Added or Changed

  * Previously, program options could be specified in full or as
    any unambiguous prefix. For example, the --compress option
    could be given to mysqldump as --compr, but not as --comp
    because the latter is ambiguous. Option prefixes now are
    deprecated. They can cause problems when new options are
    implemented for programs. A prefix that is currently
    unambiguous might become ambiguous in the future. If an
    unambiguous prefix is given, a warning now occurs to provide
    feedback. For example:
     Warning: Using unique option prefix compr instead of compress
     is deprecated and will be removed in a future release. Please
     use the full name instead.
    Option prefixes are no longer supported in MySQL 5.7; only
    full options are accepted. (Bug #16996656)

  * comp_err now checks to make sure that new errors are not being
    added to MySQL 5.1 or 5.5 because the set of errors for these
    series is frozen. (Bug #16807394)

Bugs Fixed

  * MySQL Cluster: CREATE LOGFILE GROUP failed with a syntax error
    when INITIAL_SIZE, UNDO_BUFFER_SIZE, or both options were
    specified. (Bug #13116514)

  * InnoDB: InnoDB would fail to open a tablespace that has
    multiple data files. (Bug #17033706, Bug #69623)

  * InnoDB: When CHECK TABLE found a secondary index that
    contained the wrong number of entries, it would report an
    error but not mark the index as corrupt. CHECK TABLE now marks
    the index as corrupt when this error is encountered, but only
    the index is marked as corrupt, not the table. As a result,
    only the index becomes unusable until it is dropped and
    rebuilt. The table is unaffected. (Bug #16914007)

  * InnoDB: InnoDB would attempt to gather statistics on partially
    created indexes. (Bug #16907783)

  * InnoDB: The two INFORMATION_SCHEMA tables for the InnoDB
    buffer pool could show an invalid page type for read-fixed
    blocks. This fix will show the unknown page type for blocks
    that are I/O-fixed for reading. (Bug #16859867)

  * InnoDB: During an insert buffer merge, InnoDB would invoke
    lock_rec_restore_from_page_infimum() on a potentially invalid
    record pointer. (Bug #16806366)

  * InnoDB: The page_zip_validate() consistency check would fail
    after compressing a page, in page_zip_compress(). This problem
    was caused by page_zip_decompress(), which would fail to set
    heap_no correctly when a record contained no user data bytes.
    A record with no user data bytes occurs when, for example, a
    primary key is an empty string and all secondary index fields
    are NULL or an empty string. (Bug #16736929)

  * InnoDB: During a transaction commit, prepare_commit_mutex is
    acquired to preserve the commit order. If the commit operation
    failed, the transaction would be rolled back but the mutex
    would not be released. Subsequent insert operations would not
    be able to acquire the same mutex. This fix frees
    prepare_commit_mutex during innobase_rollback. (Bug #16513588)

  * InnoDB: When the InnoDB shutdown mode (innodb_fast_shutdown)
    is set to 2 and the master thread enters the flush loop, the
    thread would not be able to exit under some circumstances.
    This could lead to a shutdown hang. (Bug #16411457)

  * InnoDB: After disabling foreign key checks with SET
    foreign_key_checks=0 and performing a DROP INDEX, the table
    was no longer accessible after restarting the server. This fix
    allows the table with missing foreign key indexes to be
    accessed when SET foreign_key_checks=0. When the table is
    accessible, the user must recreate the missing indexes to
    fulfill the foreign key constraints. (Bug #16208542, Bug
    #68148)

  * InnoDB: When InnoDB thread concurrency is enabled, there was a
    possibility that thread concurrency tickets would be released
    after each row is read resulting in a concurrency check after
    each read. A concurrency check after each read could impact
    performance of queries that return a large number of rows.
    (Bug #68869, Bug #16622478)

  * InnoDB: Creating a table with a comment or default textual
    value containing an apostrophe that is escaped with a
    backslash would sometimes cause the InnoDB storage engine to
    omit foreign key definitions. (Bug #61656, Bug #12762377)

  * InnoDB: Setting foreign_key_checks=0 and running ALTER TABLE
    to change the character set of foreign key columns for a
    database with multiple tables with foreign key constraints
    would leave the database in an inconsistent state. Subsequent
    ALTER TABLE operations (using the COPY algorithm) with
    foreign_key_checks=1 would fail due to the detected
    inconsistency. Reversion of the partially executed ALTER TABLE
    operation would also fail, resulting in the loss of the table
    being altered. When running the same ALTER TABLE operation
    with a RENAME clause, the inconsistency would not be detected
    but if the ALTER TABLE operation failed for some other reason,
    reversion of the partially executed ALTER TABLE would fail
    with the same result.
    The bug fix temporarily disables foreign_key_checks while the
    previous table definition is restored. (Bug #65701, Bug
    #14227431)

  * InnoDB: Successive deletes in descending key order would lead
    to under-filled InnoDB index pages. When an InnoDB index page
    is under-filled, it is merged with the left or right sibling
    node. The check performed to determine if a sibling node is
    available for merging was not functioning correctly. (Bug
    #68501, Bug #16417635)

  * InnoDB: The pthread_mutex, commit_threads_m, which was
    initialized but never used, has been removed from the code
    base. (Bug #60225, Bug #11829813)

  * Partitioning: When upgrading to MySQL 5.5.31 or higher, a
    message is written into the output of mysql_upgrade when
    encountering a partitioned table for which the ALGORITHM
    option is required to maintain binary compatibility with the
    original; the message includes the ALTER TABLE statement
    required to make the change. For such a table having a
    sufficiently large number of partitions, the message was
    truncated with an error before the complete ALTER TABLE
    statement could be written. (Bug #16589511)

  * Partitioning: When a range specified in the WHERE condition of
    a query against a table partitioned by RANGE entirely within
    that of one of the partitions, the next partition was also
    checked for rows although it should have been pruned away.
    Suppose we have a range-partitioned table t created using the
    following SQL statement:
     CREATE TABLE t  (
      id INT AUTO_INCREMENT,
      dt DATETIME,
      PRIMARY KEY (dt,id),
      UNIQUE KEY (id,dt)
     )
     PARTITION BY RANGE  COLUMNS(dt) (
      PARTITION p0 VALUES LESS THAN ('2013-01-01'),
      PARTITION p1 VALUES LESS THAN ('2013-01-15'),
      PARTITION p2 VALUES LESS THAN ('2013-02-01'),
      PARTITION p3 VALUES LESS THAN ('2013-02-15'),
      PARTITION pmax VALUES LESS THAN (MAXVALUE)
     );
    An example of a query that exhibited this issue when run
    against t is shown here:
     SELECT COUNT(*) FROM t
      WHERE dt >= '2013-02-01' AND dt < '2013-02-15';
    In this case, partition pmax was checked, even though the
    range given in the WHERE clause lay entirely within partition
    p3. (Bug #16447483)

  * Partitioning: When dropping a partitioned table, the table's
    .par file was deleted first, before the table definition or
    data. This meant that, if the server failed during the drop
    operation, the table could be left in an inconsistent state in
    which it could neither be accessed nor dropped.
    The fix for this problem makes the following changes:

       + Now, when dropping a partitioned table, the table's .par
         file is not removed until all table data has been
         deleted.

       + When executing DROP TABLE of a partitioned table, in the
         event that its .par file is determined to be missing, the
         table's .frm file is now immediately deleted, in effect
         forcing the drop to complete.
    (Bug #13548704, Bug #63884)

  * Replication: Some expressions employing variables were not
    handled correctly by LOAD DATA. (Bug #16753869)

  * Replication: Linker errors occurred if the header file
    log_event.h was included in an application containing multiple
    source files, because the file rpl_tblmap.cc was included in
    log_event.h. This fix moves the inclusion of rpl_tblmap.cc
    into the source files that use log_event.h. (Bug #16607258)

  * Installation of Solaris PKG packages could fail to execute
    mysql_install_db because it was invoked with the
    --random-passwords option (which does not exist until MySQL
    5.6). (Bug #17160741)

  * Initialization of keycache_* variables (see Multiple Key
    Caches
    (http://dev.mysql.com/doc/refman/5.5/en/multiple-key-caches.ht
    ml)) during server startup could write to incorrect memory.
    (Bug #16945503)

  * Removing a server RPM package did not shut down the existing
    server if it was running. (Bug #16798868)

  * The code base was modified to account for new warning checks
    introduced by gcc 4.8. (Bug #16729109)

  * Upgrading from community SLES RPM packages to commercial
    packages for the same MySQL version failed with conflict
    errors. (Bug #16545296)

  * A user variable referenced during execution of a prepared
    statement is set to memory that is freed at the end of
    execution. A second execution of the statement could result in
    Valgrind warnings when accessing this memory. (Bug #16119355)

  * Misoptimization of left expressions in prepared statements
    could cause a server exit. (Bug #16095534)

  * Out-of-bounds reads could occur within
    filename_to_tablename(). (Bug #14834378)

  * When running a query on INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
    that requested table_name and index_name values, query results
    would include index pages without table_name or index_name
    values. (Bug #14529666)

  * With the thread pool plugin in use, normal connection
    termination caused the Aborted_clients status variable to be
    incremented. (Bug #14081240)

  * MySQL Installer, if run in custom install or change mode,
    offered installation options that had no effect. (Bug
    #12928601)

  * Incorrect results could be returned from queries that used
    several aggr_func(DISTINCT) functions (where aggr_func() is an
    aggregate function such as COUNT()) when these referred to
    different columns of the same composite key. (Bug #12328597)

  * Assigning the result of a subquery to a user variable raised
    an assertion when the outer query included DISTINCT and GROUP
    BY. (Bug #57196, Bug #11764371)

  * mysqldump assumed the existence of the general_log and
    slow_log tables in the mysql database. It failed if invoked to
    dump tables from an older server where these tables do not
    exist. (Bug #65670, Bug #14236170)

  * Attempts to build from a source RPM package could fail because
    the build process attempted to refer to a pb2user that might
    not exist. (Bug #64641, Bug #13865797, Bug #69339, Bug
    #16874980)

  * A typo in cmake/dtrace.cmake prevented DTrace support from
    being enabled by -DENABLE_DTRACE-on. (Bug #60743, Bug
    #12325449)

  * RPM source packages did not list libaio-devel as a dependency,
    causing builds to fail. (Bug #69158, Bug #16785036)

On Behalf of Oracle MySQL RE Team

Hery Ramilison
Oracle/MySQL Release Engineer