MySQL Forums
Forum List  »  Announcements

MySQL 5.1.29-rc has been released
Posted by: Kent Boortz
Date: October 27, 2008 03:42PM

Dear MySQL users,


We are proud to present to you the MySQL Server 5.1.29-rc release,
a new "release candidate" version of the popular open source database.

Bear in mind that this is still a "candidate" release, and as with any
other pre-production release, caution should be taken when installing
on production level systems or systems with critical data.
For production level systems using 5.0, we would like to direct your
attention to the product description of MySQL Enterprise at:

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

The MySQL 5.1.29-rc release is now available in source and binary form
for a number of platforms from our download pages at

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

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,
patches etc.:

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

The following section lists the changes from version to version in the
MySQL source code since the latest released version of MySQL 5.1, the
MySQL 5.1.28-rc release. It can also be viewed online at

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-29.html

Sincerely,

Kent Boortz
The MySQL build team at Sun Microsystems

Functionality added or changed:

  * Important Change: The --skip-thread-priority option is now
    deprecated in MySQL 5.1 and is removed in MySQL 6.0 such that
    the server won't change the thread priorities by default.

    Giving threads different priorities might yield marginal
    improvements in some platforms (where it actually works), but
    it might instead cause significant degradation depending on
    the thread count and number of processors. Meddling with the
    thread priorities is a not a safe bet as it is very dependent
    on the behavior of the CPU scheduler and system where MySQL is
    being run.
    (Bug#35164: http://bugs.mysql.com/35164,
     Bug#37536: http://bugs.mysql.com/37536)

  * Important Change: The --log option now is deprecated and will
    be removed (along with the log system variable) in the future.
    Instead, use the --general_log option to enable the general
    query log and the --general_log_file=file_name option to set
    the general query log filename. The values of these options
    are available in the general_log and general_log_file system
    variables, which can be changed at runtime.

    Similar changes were made for the --log-slow-queries option
    and log_slow_queries system variable. You should use the
    --slow_query_log and --slow_query_log_file=file_name options
    instead (and the slow_query_log and slow_query_log_file system
    variables).

  * The SHOW PROFILES and SHOW PROFILE statements were added to
    display statement profile data, and the accompanying
    "INFORMATION_SCHEMA.PROFILING" table. Profiling is controlled
    via the 'profiling' and 'profiling_history_size' session
    variables. (Community contribution by Jeremy Cole)

  * The BUILD/compile-solaris-* scripts now compile MySQL with the
    mtmalloc library rather than malloc.
    (Bug#38727: http://bugs.mysql.com/38727)

Bugs fixed:

  * Incompatible Change: Replication: The default binary logging
    mode has been changed from MIXED to STATEMENT for
    compatibility with MySQL 5.0.
    (Bug#39812: http://bugs.mysql.com/39812)

  * Incompatible Change: In connection with view creation, the
    server created arc directories inside database directories and
    maintained useless copies of .frm files there. Creation and
    renaming procedures of those copies as well as creation of arc
    directories has been discontinued.

    This change does cause a problem when downgrading to older
    server versions which manifests itself under these
    circumstances:

      1. Create a view v_orig in MySQL 5.1.29 or higher.
      2. Rename the view to v_new and then back to v_orig.
      3. Downgrade to an older 5.1.x server and run mysql_upgrade.
      4. Try to rename v_orig to v_new again. This operation
         fails.

    As a workaround to avoid this problem, use either of these
    approaches:
       + Dump your data using mysqldump before downgrading and
         reload the dump file after downgrading.
       + Instead of renaming a view after the downgrade, drop it
         and recreate it.
    (Bug#17823: http://bugs.mysql.com/17823)
    See also Bug#40021: http://bugs.mysql.com/40021

  * Important Change: Replication: The SUPER privilege is now
    required to change the session value of binlog_format as well
    as its global value. For more information about binlog_format,
    see Section 15.1.2, "Replication Formats."
    (Bug#39106: http://bugs.mysql.com/39106)

  * Partitioning: Replication: Replication to partitioned MyISAM
    tables could be slow with row-based binary logging.
    (Bug#35843: http://bugs.mysql.com/35843)

  * Partitioning: If an error occurred when evaluating a column of
    a partitioned table for the partitioning function, the row
    could be inserted anyway.
    (Bug#38083: http://bugs.mysql.com/38083)

  * Partitioning: Using INSERT ... SELECT to insert records into a
    partitioned MyISAM table could fail if some partitions were
    empty and others are not.
    (Bug#38005: http://bugs.mysql.com/38005)

  * Partitioning: Ordered range scans on partitioned tables were
    not always handled correctly. In some cases this caused some
    rows to be returned twice. The same issue also caused GROUP BY
    query results to be aggregated incorrectly.
    (Bug#30573: http://bugs.mysql.com/30573,
     Bug#33257: http://bugs.mysql.com/33257,
     Bug#33555: http://bugs.mysql.com/33555)

  * Replication: Server code used in binary logging could in some
    cases be invoked even though binary logging was not actually
    enabled, leading to asserts and other server errors.
    (Bug#38798: http://bugs.mysql.com/38798)

  * Replication: Replication of BLACKHOLE tables did not work with
    row-based binary logging.
    (Bug#38360: http://bugs.mysql.com/38360)

  * Replication: In some cases, a replication master sent a
    special event to a reconnecting slave to keep the slave's
    temporary tables, but they still had references to the "old"
    slave SQL thread and used them to access that thread's data.
    (Bug#38269: http://bugs.mysql.com/38269)

  * Replication: Replication filtering rules were inappropiately
    applied when executing BINLOG pseudo-queries. One way in which
    this problem showed itself was that, when replaying a binary
    log with mysqlbinlog, RBR events were sometimes not executed
    if the --replicate-do-db option was specified. Now replication
    rules are applied only to those events executed by the slave
    SQL thread.
    (Bug#36099: http://bugs.mysql.com/36099)

  * Replication: For a CREATE TABLE ... SELECT statement that
    creates a table in a database other than the current one, the
    table could be created in the wrong database on replication
    slaves if row-based binary logging is used.
    (Bug#34707: http://bugs.mysql.com/34707)

  * Replication: A statement did not always commit or roll back
    correctly when the server was shut down; the error could be
    triggered by having a failing UPDATE or INSERT statement on a
    transactional table, causing an implicit rollback.
    (Bug#32709: http://bugs.mysql.com/32709)
    See also Bug#38262: http://bugs.mysql.com/38262

  * CHECK TABLE ... FOR UPGRADE did not check for incompatible
    collation changes made in MySQL 5.0.48.
    (Bug#39585: http://bugs.mysql.com/39585)

  * The Sun Studio compiler failed to build debug versions of the
    server due to use of features specific to gcc.
    (Bug#39451: http://bugs.mysql.com/39451)

  * For a TIMESTAMP column in an InnoDB table, testing the column
    with multiple conditions in the WHERE clause caused a server crash.
    (Bug#39353: http://bugs.mysql.com/39353)

  * References to local variables in stored procedures are
    replaced with NAME_CONST(name, value) when written to the
    binary log. However, an "illegal mix of collation" error might
    occur when executing the log contents if the value's collation
    differed from that of the variable. Now information about the
    variable collation is written as well.
    (Bug#39182: http://bugs.mysql.com/39182)

  * Queries of the form SELECT ... REGEXP BINARY NULL could lead
    to a hung or crashed server.
    (Bug#39021: http://bugs.mysql.com/39021)

  * Statements of the form INSERT ... SELECT .. ON DUPLICATE KEY
    UPDATE col_name = DEFAULT could result in a server crash.
    (Bug#39002: http://bugs.mysql.com/39002)

  * Column names constructed due to wild-card expansion done
    inside a stored procedure could point to freed memory if the
    expansion was performed after the first call to the stored
    procedure. (Bug#38823: http://bugs.mysql.com/38823)

  * Repeated CREATE TABLE ... SELECT statements, where the created
    table contained an AUTO_INCREMENT column, could lead to an
    assertion failure. (Bug#38821: http://bugs.mysql.com/38821)

  * For deadlock between two transactions that required a timeout
    to resolve, all server tables became inaccessible for the
    duration of the deadlock.
    (Bug#38804: http://bugs.mysql.com/38804)

  * When inserting a string into a duplicate-key error message,
    the server could improperly interpret the string, resulting in
    a crash. (Bug#38701: http://bugs.mysql.com/38701)

  * A race condition between threads sometimes caused unallocated
    memory to be addressed.
    (Bug#38692: http://bugs.mysql.com/38692)

  * A server crash resulted from concurrent execution of a
    multiple-table UPDATE that used a NATURAL or USING join
    together with FLUSH TABLES WITH READ LOCK or ALTER TABLE for
    the table being updated.
    (Bug#38691: http://bugs.mysql.com/38691)

  * On ActiveState Perl, mysql-test-run.pl --start-and-exit
    started but did not exit.
    (Bug#38629: http://bugs.mysql.com/38629)

  * An uninitialized variable in the query profiling code was
    corrected (detected by Valgrind).
    (Bug#38560: http://bugs.mysql.com/38560)

  * A server crash resulted from execution of an UPDATE that used
    a derived table together with FLUSH TABLES.
    (Bug#38499: http://bugs.mysql.com/38499)

  * Stored procedures involving substrings could crash the server
    on certain platforms due to invalid memory reads.
    (Bug#38469: http://bugs.mysql.com/38469)

  * The handlerton-to-plugin mapping implementation did not free
    handler plugin references when the plugin was uninstalled,
    resulting in a server crash after several install/uninstall
    cycles. Also, on Mac OS X, the server crashed when trying to
    access an EXAMPLE table after the EXAMPLE plugin was
    installed.
    (Bug#37958: http://bugs.mysql.com/37958)

  * The server crashed if an argument to a stored procedure was a
    subquery that returned more than one row.
    (Bug#37949: http://bugs.mysql.com/37949)

  * When analyzing the possible index use cases, the server was
    incorrectly reusing an internal structure, leading to a server
    crash.
    (Bug#37943: http://bugs.mysql.com/37943)

  * Access checks were skipped for SHOW PROCEDURE STATUS and SHOW
    FUNCTION STATUS, which could lead to a server crash or
    insufficient access checks in subsequent statements.
    (Bug#37908: http://bugs.mysql.com/37908)

  * The <=> operator could return incorrect results when comparing
    NULL to DATE, TIME, or DATETIME values.
    (Bug#37526: http://bugs.mysql.com/37526)

  * The combination of a subquery with a GROUP BY, an aggregate
    function calculated outside the subquery, and a GROUP BY on
    the outer SELECT could cause the server to crash.
    (Bug#37348: http://bugs.mysql.com/37348)

  * The NO_BACKSLASH_ESCAPES SQL mode was ignored for LOAD DATA
    INFILE and SELECT INTO ... OUTFILE. The setting is taken into
    account now.
    (Bug#37114: http://bugs.mysql.com/37114)

  * In some cases, references to views were confused with
    references to anonymous tables and privilege checking was not
    performed.
    (Bug#36086: http://bugs.mysql.com/36086)

  * For crash reports on Windows, symbol names in stack traces
    were not correctly resolved.
    (Bug#35987: http://bugs.mysql.com/35987)

  * ALTER EVENT changed the PRESERVE attribute of an event even
    when PRESERVE was not specified in the statement.
    (Bug#35981: http://bugs.mysql.com/35981)

  * Hostname values in SQL statements were not being checked for
    '@', which is illegal according to RFC952.
    (Bug#35924: http://bugs.mysql.com/35924)

  * mysql_install_db failed on machines that had the hostname set
    to localhost.
    (Bug#35754: http://bugs.mysql.com/35754)

  * Dynamic plugins failed to load on i5/OS.
    (Bug#35743: http://bugs.mysql.com/35743)

  * With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled, a ucs2 CHAR
    column returned additional garbage after trailing space
    characters.
    (Bug#35720: http://bugs.mysql.com/35720)

  * With binary logging enabled, CREATE TABLE ... SELECT failed if
    the source table was a log table.
    (Bug#34306: http://bugs.mysql.com/34306)

  * A trigger for an InnoDB table activating multiple times could
    lead to AUTO_INCREMENT gaps.
    (Bug#31612: http://bugs.mysql.com/31612)

  * mysqldump could fail to dump views containing a large number
    of columns.
    (Bug#31434: http://bugs.mysql.com/31434)

  * The server could improperly type user-defined variables used
    in the select list of a query.
    (Bug#26020: http://bugs.mysql.com/26020)

  * For access to the INFORMATION_SCHEMA.VIEWS table, the server
    did not check the SHOW VIEW and SELECT provileges, leading to
    inconsistency between output from that table and the SHOW
    CREATE VIEW statement.
    (Bug#22763: http://bugs.mysql.com/22763)

  * mysqld_safe would sometimes fail to remove the pid file for
    the old mysql process after a crash. As a result, the server
    would fail to start due to a false A mysqld process already
    exists... error.
    (Bug#11122: http://bugs.mysql.com/11122)

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL 5.1.29-rc has been released
8712
October 27, 2008 03:42PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.