MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.1.59 has been released
Posted by: Karen Langford
Date: September 16, 2011 09:35AM

Dear MySQL users,

MySQL Server 5.1.59, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.1.59 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.59 on new servers or upgrading
to MySQL 5.1.59 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


D.1.2. Changes in MySQL 5.1.59 (15 September, 2011)

   Functionality Added or Changed

     * If the --with-ndbcluster option is given to the configure
       script, it now produces a warning that the version of MySQL
       Cluster included in 5.1 is no longer maintained. (The separate
       MySQL Cluster distribution should be used instead.) (Bug
       #49093, Bug #11757091)

   Bugs Fixed

     * InnoDB Storage Engine: The "random read-ahead
       los_read_ahead)" feature that was removed from the InnoDB
       Plugin is now available again. Because it is only helpful for
       certain workloads, it is turned off by default. To turn it on,
       enable the innodb_random_read_ahead configuration option.
       Because this feature can improve performance in some cases and
       reduce performance in others, before relying on this setting,
       benchmark both with and without the setting enabled. (Bug

     * Partitioning: Auto-increment columns of partitioned tables
       were checked even when they were not being written to. In
       debug builds, this could lead to a server crash. (Bug
       #11765667, Bug #58655)

     * The option-parsing code for empty strings leaked memory. (Bug

     * Replication: Processing of corrupted table map events could
       cause the server to crash. This was especially likely if the
       events mapped different tables to the same identifier, such as
       could happen due to Bug#56226.
       Now, before applying a table map event, the server checks
       whether the table has already been mapped with different
       settings, and if so, an error is raised and the slave SQL
       thread stops. If it has been mapped with the same settings, or
       if the table is set to be ignored by filtering rules, there is
       no change in behavior: the event is skipped and IDs are not
       checked. (Bug #44360, Bug #11753004)
       See also Bug #11763509.

     * ALTER TABLE {MODIFY|CHANGE} ... FIRST did nothing except
       rename columns if the old and new versions of the table had
       exactly the same structure with respect to column data types.
       As a result, the mapping of column name to column data was
       incorrect. The same thing happened for ALTER TABLE DROP COLUMN
       ... ADD COLUMN statements intended to produce a new version of
       the table with exactly the same structure as the old version.
       (Bug #61493, Bug #12652385)

     * For a lower_case_table_names value of 1 or 2 and a database
       having a mixed-case name, calling a stored function using a
       fully qualified name including the database name failed. (Bug
       #60347, Bug #11840395)

     * Previously, Performance Schema table columns that held byte
       counts were BIGINT UNSIGNED. These were changed to BIGINT
       (signed). This makes it easier to perform calculations that
       compute differences between columns. (Bug #59631, Bug

     * For MyISAM tables, attempts to insert incorrect data into an
       indexed GEOMETRY column could result in table corruption. (Bug
       #57323, Bug #11764487)

     * A race condition between loading a stored routine using the
       name qualified by the database name and dropping that database
       resulted in a spurious error message: The table mysql.proc is
       missing, corrupt, or contains bad data (Bug #47870, Bug

     * Upgrades using an RPM package recreated the test database,
       which is undesirable when the DBA had removed it. (Bug #45415,
       Bug #11753896)
Database Group, Oracle.

Options: ReplyQuote

Written By
MySQL Community Server 5.1.59 has been released
September 16, 2011 09:35AM

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.