MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Karen Langford Date:January 31 2010 3:39pm
Subject:MySQL Community Server 5.1.43 has been released
View as plain text  
Dear MySQL users,

MySQL Community Server 5.1.43, a new version of the popular Open
Source Database Management System, has been released.  MySQL 5.1.43 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.43 on new servers or upgrading
to MySQL 5.1.43 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 following section lists the changes in the MySQL source code since
the previous released version of MySQL 5.1.  It may also be viewed
online at



C.1.2. Changes in MySQL 5.1.43

   InnoDB Plugin Notes:

     * This release includes InnoDB Plugin 1.0.6. This version is
       considered of Release Candidate (RC) quality.

   Functionality added or changed:

     * Partitioning: The UNIX_TIMESTAMP() function is now supported
       in partitioning expressions using TIMESTAMP columns. For
       example, it now possible to create a partitioned table such as
       this one:
    PARTITION p0 VALUES LESS THAN (631148400),
    PARTITION p1 VALUES LESS THAN (946681200),
       All other expressions involving TIMESTAMP values are now
       rejected with an error when attempting to create a new
       partitioned table or to alter an existing partitioned table.
       When accessing an existing partitioned table having a
       timezone-dependent partitioning function (where the table was
       using a previous version of MySQL), a warning rather than an
       error is issued. In such cases, you should fix the table. One
       way of doing this is to alter the table's partitioning
       expression so that it uses UNIX_TIMESTAMP().

   Bugs fixed:

     * Security Fix: For servers built with yaSSL, a preauthorization
       buffer overflow could cause memory corruption or a server
       crash. We thank Evgeny Legerov from Intevydis for providing us
       with a proof-of-concept script that allowed us to reproduce
       this bug. (Bug#50227:,

     * Important Change: Replication: The RAND() function is now
       marked as unsafe for statement-based replication. Using this
       function now generates a warning when binlog_format=STATEMENT
       and causes the the format to switch to row-based logging when
       This change is being introduced because, when RAND() was
       logged in statement mode, the seed was also written to the
       binary log, so the replication slave generated the same
       sequence of random numbers as was generated on the master.
       While this could make replication work in some cases, the
       order of affected rows was still not guaranteed when this
       function was used in statements that could update multiple
       rows, such as UPDATE or INSERT ... SELECT; if the master and
       the slave retrieved rows in different order, they began to
       diverge. (Bug#49222:

     * Partitioning: When used on partitioned tables, the
       records_in_range handler call checked all partitions, rather
       than the unpruned partitions only.
       See also Bug#37252:,

     * Partitioning: A query that searched on a ucs2 column failed if
       the table was partitioned.

     * Replication: A LOAD DATA INFILE statement that loaded data
       into a table having a column name that must be escaped (such
       as `key` INT), caused replication to fail when logging in
       mixed or statement mode. In such cases, the master wrote the
       LOAD DATA event to the binary log without escaping the field
       names. (Bug#49473:
       See also Bug#47927:

     * Replication: Spatial data types cause row-based replication to
       crash. (Bug#48776:

     * Replication: A flaw in the implementation of the purging of
       binary logs could result in orphaned files being left behind
       in the following circumstances:

          + If the server failed or was killed while purging binary
            If the server failed or was killed after creating of a
            new binary log when the new log file was opened for the
            first time.
       In addition, if the slave was not connected during the purge
       operation, it was possible for a log file that was in use to
       be removed; this could lead data loss and possible
       inconsistencies between the master and slave.

     * Replication: When using the STATEMENT or MIXED logging format,
       LOAD DATA LOCAL INFILE, respectively (in other words, the
       CONCURRENT keyword was omitted). As a result, when using
       replication with either of these logging modes, queries on the
       slaves were blocked by the replication SQL thread while trying
       to execute the affected statements.

     * Replication: Manually removing entries from the binary log
       index file on a replication master could cause the server to
       repeatedly send the same binary log file to slaves.

     * Cluster Replication: When expire_logs_days was set, the thread
       performing the purge of the log files could deadlock, causing
       all binary log operations to stop.

     * Within a stored routine, selecting the result of CONCAT_WS()
       with a routine parameter argument into a user variable could
       return incorrect results.

     * The IBMDB2I storage engine was missing from the i5os 64-bit
       distribution of MySQL 5.1.42. It is now included again.

     * EXPLAIN EXTENDED UNION ... ORDER BY caused a crash when the
       ORDER BY referred to a nonconstant or full-text function or a
       subquery. (Bug#49734:

     * The push_warning_printf() function was being called with an
       invalid error level MYSQL_ERROR::WARN_LEVEL_ERROR, causing an
       assertion failure. To fix the problem,
       MYSQL_ERROR::WARN_LEVEL_ERROR has been replaced by

     * Some prepared statements could raise an assertion when

     * A Valgrind error in make_cond_for_table_from_pred() was
       corrected. Thanks to Sergey Petrunya for the patch to fix this
       bug. (Bug#49506:

     * When compiling on Windows, an error in the CMake definitions
       for InnoDB would cause the engine to be built incorrectly.

     * Valgrind warnings for CHECKSUM TABLE were corrected.

     * Specifying an index algorithm (such as BTREE) for SPATIAL or
       FULLTEXT indexes caused a server crash. These index types do
       not support algorithm specification, and it is now disallowed
       to do so. (Bug#49250:

     * The optimizer sometimes incorrectly handled conditions of the
       form WHERE col_name='const1' AND col_name='const2'.

     * Execution of DECODE() and ENCODE() could be inefficient
       because multiple executions within a single statement
       reinitialized the random generator multiple times even with
       constant parameters.

     * MySQL 5.1 does not support 2-byte collation numbers, but did
       not check the number and crashed for out-of-range values.

     * With binary logging enabled, REVOKE ... ON
       {PROCEDURE|FUNCTION} FROM ... could cause a crash.

     * The LIKE operator did not work correctly when using an index
       for a ucs2 column.

     * check_key_in_view() was missing a DBUG_RETURN in one code
       branch, causing a crash in debug builds.

     * Several strmake() calls had an incorrect length argument (too
       large by one).

     * On Fedora 12, strmov() did not guarantee correct operation for
       overlapping source and destination buffer. Calls were fixed to
       use an overlap-safe version instead.

     * Incomplete reset of internal TABLE structures could cause a
       crash with eq_ref table access in subqueries.

     * Re-execution of a prepared statement could cause a server
       crash. (Bug#48508:

     * The error message for ER_UPDATE_INFO was subject to buffer
       overflow or truncation.

     * SHOW BINLOG EVENTS could fail with a error: Wrong offset or
       I/O error. (Bug#48357:

     * Valgrind warnings related to binary logging of LOAD DATA
       INFILE statements were corrected.

     * An aliasing violation in the C API could lead to a crash.

     * The InnoDB Monitor could fail to print diagnostic information
       after a long lock wait.

     * Queries containing GROUP BY ... WITH ROLLUP that did not use
       indexes could return incorrect results.

     * If an invocation of a stored procedure failed in the
       table-open stage, subsequent invocations that did not fail in
       that stage could cause a crash.

     * On Solaris, no stack trace was printed to the error log after
       a crash. (Bug#47391:

     * The first execution of STOP SLAVE UNTIL stopped too early.

     * When the mysql client was invoked with the --vertical option,
       it ignored the --skip-column-names option.

     * It was possible for init_available_charsets() not to
       initialize correctly.

     * Comparison with NULL values sometimes did not produce a
       correct result.

     * Crash recovery did not work for InnoDB temporary tables.

     * The mysql_upgrade command would create three additional fields
       to the mysql.proc table (character_set_client,
       collation_connection, and db_collation), but did not populate
       the fields with correct values. This would lead to error
       messages reported during stored procedure execution.

     * When compressed MyISAM files were opened, they were always
       memory mapped, sometimes causing memory-swapping problems. To
       deal with this, a new system variable, myisam_mmap_size, was
       added to limit the amount of memory used for memory mapping of
       MyISAM files.

     * A race condition on the privilege hash tables allowed one
       thread to try to delete elements that had already been deleted
       by another thread. A consequence was that SET PASSWORD or
       FLUSH PRIVILEGES could cause a crash.

     * ALTER TABLE with both DROP COLUMN and ADD COLUMN clauses could
       crash or lock up the server.


Karen Langford, Hery Ramilison, MySQL Release Engineers
Database Group, Sun Microsystem Inc.

MySQL Community Server 5.1.43 has been releasedKaren Langford31 Jan