MySQL Forums
Forum List  »  Announcements

MySQL Server 5.1.37 has been released
Posted by: Timothy Smith
Date: August 02, 2009 02:14PM

Dear MySQL users,

MySQL Community Server 5.1.37, a new version of the popular Open
Source Database Management System, has been released. MySQL 5.1.37 is
recommended for use on production systems.

For an overview of what's new in MySQL 5.1, please see

For information on installing MySQL 5.1.37 on new servers or upgrading
from previous MySQL releases, please see

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

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

For information on open issues in MySQL 5.1, please see the errata
list at

The end of this message lists the changes in MySQL Server since
the previous released version of MySQL 5.1. It may also be viewed
online at



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#44270:
    See also Bug#34654:

Bugs fixed:

  * Security Fix: Partitioning: Accessing a table with user-defined
    partitioning when the server SQL mode included ONLY_FULL_GROUP_BY
    caused the MySQL server to crash. For example, the following
    sequence of statements crashed the server:



    CREATE TABLE t1(id INT, key(id))


  * Important Change: Replication: When using STATEMENT or MIXED
    binary logging format, a statement that changes both
    non-transactional and transactional tables must be written to
    the binary log whenever there are changes to non-transactional
    tables. This means that the statement goes into the binary log
    even when the changes to the transactional tables fail. In
    particular, in the event of a failure such statement is
    annotated with the error number and wrapped inside a pair of
    BEGIN and ROLLBACK statements.
    On the slave, while applying the statement, it is expected
    that the same failure and the rollback prevent the
    transactional changes from persisting. However, statements
    that fail due to concurrency issues such as deadlocks and
    timeouts are logged in the same way, causing the slave to stop
    since the statements are applied sequentially by the SQL
    To address this issue, we ignore concurrency failures on the
    slave. Specifically, the following failures are now ignored:

  * Partitioning: Truncating a partitioned MyISAM table did not
    reset the AUTO_INCREMENT value.

  * Replication: The SHOW SLAVE STATUS connection thread competed
    with the slave SQL thread for use of the error message buffer.
    As a result, the connection thread sometimes received
    incomplete messages. This issue was uncovered with valgrind
    when message strings were passed without NULL terminators,
    causing the error Conditional jump or move depends on
    uninitialised value(s).
    See also Bug#43076:

  * Replication: Large transactions and statements could corrupt
    the binary log if the size of the cache (as set by
    max_binlog_cache_size) was not large enough to store the
    Now, for transactions that do not fit into the cache, the
    statement is not logged, and the statement generates an error
    For non-transactional changes that do not fit into the cache,
    the statement is also not logged --- an incident event is
    logged after committing or rolling back any pending
    transaction, and the statement then raises an error.

    If a failure occurs before the incident event is written the
    binary log, the slave does not stop, and the master does not
    report any errors.
    See also Bug#37148:

  * Replication: The --database option for mysqlbinlog was ignored
    when using the row-based logging format.

  * Replication: Shutting down the server while executing FLUSH
    LOGS, CHANGE MASTER TO, or STOP SLAVE could sometimes cause
    mysqld to crash. (Bug#38240:

  * Replication: When reading a binary log that was in use by a
    master or that had not been properly closed (possibly due to a
    crash), the following message was printed: Warning: this
    binlog was not closed properly. Most probably mysqld crashed
    writing it. This message did not take into account the
    possibility that the file was merely in use by the master,
    which caused some users concern who were not aware that this
    could happen.
    To make this clear, the original message has been replaced
    with Warning: this binlog is either is use or was not closed
    properly. (Bug#34687:

  * The server crashed if evaluation of GROUP_CONCAT(... ORDER BY)
    required allocation of a sort buffer but allocation failed.

  * When creating tables using the IBMDB2I storage engine with the
    ibmdb2i_create_index_option option set to 1, creating an
    IBMDB2I table with a primary key should produce an additional
    index that uses EBCDIC hexadecimal sorting, but this index was
    not created. (Bug#45983:

  * With InnoDB tables, MySQL used a less-selective secondary
    index to avoid a filesort even if a prefix of the primary key
    was much more selective.
    The fix for this problem might cause other queries to run more
    slowly. (Bug#45828:

  * The server crashed for attempts to use REPLACE or INSERT ...
    ON DUPLICATE KEY UPDATE with a view defined using a join.

  * Some collations were causing IBMDB2I to report inaccurate key
    range estimations to the optimizer for LIKE clauses that
    select substrings. This can be seen by running EXPLAIN. This
    problem primarily affects multi-byte and unicode character
    sets. (Bug#45803:

  * Invalid memory reads and writes were generated when altering
    merge and base tables. This could lead to a crash or Valgrind
    ==28038== Invalid write of size 1
    at: memset (mc_replace_strmem.c:479)
    by: myrg_attach_children (myrg_open.c:433)
    by: ha_myisammrg::attach_children() (
    by: ha_myisammrg::extra(ha_extra_function) (
    by: attach_merge_children(TABLE_LIST*) (
    by: open_tables(THD*, TABLE_LIST**, unsigned*, unsigned) (
    by: open_and_lock_tables_derived(THD*, TABLE_LIST*, bool) (sql_base.c
    by: open_n_lock_single_table (mysql_priv.h:1550)
    by: mysql_alter_table(
    by: mysql_execute_command(THD*) (
    by: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse
    by: dispatch_command (

  * Inserting data into a table using the macce character set with
    the IBMDB2I storage engine would fail.

  * There was a race condition when changing
    innodb_commit_concurrency at runtime to the value DEFAULT.
    See also Bug#42101:

  * Performing an empty XA transaction caused the server to crash
    for the next XA transaction.

  * For replication of a stored procedure that uses the gbk
    character set, the result on the master and slave differed.

  * SHOW CREATE TRIGGER requires the TRIGGER privilege but was not
    checking privileges. (Bug#45412:

  * An assertion failure could occur if InnoDB tried to unlock a
    record when the clustered index record was unknown.

  * Bug#19027: caused
    --enable-plugin_name (for example, --enable-innodb) not to
    work. (Bug#45336:

  * If autocommit was enabled, InnoDB did not roll back DELETE or
    UPDATE statements if the statement was killed.

  * Use of DECIMAL constants with more than 65 digits in CREATE
    TABLE ... SELECT statements led to spurious errors or
    assertion failures. (Bug#45262:

  * The mysql client could misinterpret some character sequences
    as commands under some circumstances.

  * Use of CONVERT() with an empty SET value could cause an
    assertion failure. (Bug#45168:

  * InnoDB recovery could hang due to redo logging of doublewrite
    buffer pages. (Bug#45097:

  * when reading binary data, the concatenation function for
    geometry data collections did not rigorously check for
    available data, leading to invalid reads and server crashes.

  * If an error occurred during the creation of a table (for
    example, the table already existed) having an AUTO_INCREMENT
    column and a BEFORE trigger that used the INSERT ... SELECT
    construct, an internal flag was not reset properly. This led
    to a crash the next time that the table was opened again.

  * For queries with a sufficient number of subqueries in the FROM
    clause of this form:
                  (SELECT 2) AS t2,
                  (SELECT 3) AS t3, ...
    The query failed with a Too high level of nesting for select
    error, as though the query had this form:

  * contained references to literal instances of nm
    and libc, rather than to variables parameterized for the
    proper values on the current platform.

  * did not properly check for the
    pthread_setschedprio() function.

  * A workaround for a Sun Studio bug was instituted.

  * Valgrind warnings that occurred for SHOW TABLE STATUS with
    InnoDB tables were silenced.

  * In the mysql client, if the server connection was lost during
    repeated status commands, the client would fail to detect this
    and command output would be inconsistent.

  * When invoked to start multiple server instances, mysqld_multi
    sometimes would fail to start them all due to not changing
    location into the base directory for each instance.

  * Renaming a column that appeared in a foreign key definition
    did not update the foreign key definition with the new column
    name. (Bug#21704:

Timothy Smith, Release Engineering, MySQL
Database Technology Group, Sun Microsystems

Options: ReplyQuote

Written By
MySQL Server 5.1.37 has been released
August 02, 2009 02:14PM

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.