MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.1.65 has been released
Posted by: Bjørn Munch
Date: August 09, 2012 01:21AM

Dear MySQL users,

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

Note: there is no release named 5.1.64, so this version directly
follows 5.1.63.

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

For information on installing MySQL 5.1.65 on new servers or upgrading
to MySQL 5.1.65 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.65 (August 9, 2012)

   Functionality Added or Changed

     * Important Change: The YEAR(2) data type is now deprecated
       because it is problematic. Support for YEAR(2) will be removed
       in a future release of MySQL. For more information, see
       Section 11.3.4, "YEAR(2) Limitations and Migrating to

     * Important Change: Replication: The SHOW BINARY LOGS statement
       (and its equivalent SHOW MASTER LOGS) may now be executed by a
       user with the REPLICATION CLIENT privilege. (Formerly, the
       SUPER privilege was necessary to use either form of this

   Bugs Fixed

     * The server did not build with gcc 4.7. (Bug #14238406)

     * InnoDB: If a row was deleted from an InnoDB table, then
       another row was re-inserted with the same primary key value,
       an attempt by a concurrent transaction to lock the row could
       succeed when it should have waited. This issue occurred if the
       locking select used a WHERE clause that performed an index
       scan using a secondary index. (Bug #14100254, Bug #65389)

     * InnoDB: In a transaction using the REPEATABLE READ isolation
       level, an UPDATE or DELETE statement for an InnoDB table could
       sometimes overlook rows recently committed by other
       transactions. As explained in Consistent Nonlocking Reads
       .html), DML statements within a REPEATABLE READ transaction
       apply to rows committed by other transactions, even if a query
       could not see those rows. (Bug #14007649, Bug #65111)

     * InnoDB: Using the KILL statement to terminate a query could
       cause an unnecessary message in the error log:
       [ERROR] Got error -1 when reading table table_name
       (Bug #13933132)

     * InnoDB: For an InnoDB table with a trigger, under the setting
       innodb_autoinc_lock_mode=1, sometimes auto-increment values
       could be interleaved when inserting into the table from two
       sessions concurrently. The sequence of auto-increment values
       could vary depending on timing, leading to data inconsistency
       in systems using replication. (Bug #12752572, Bug #61579)

     * InnoDB: The CHECK TABLE statement could fail for a large
       InnoDB table due to a timeout value of 2 hours. For typical
       storage devices, the issue could occur for tables that
       exceeded approximately 200 or 350 GB, depending on I/O speed.
       The fix relaxes the locking performed on the table being
       checked, which makes the timeout less likely. It also makes
       InnoDB recognize the syntax CHECK TABLE QUICK, which avoids
       the possibility of the timeout entirely. (Bug #11758510, Bug

     * Replication: It was theoretically possible for concurrent
       execution of more than one instance of SHOW BINLOG EVENTS to
       crash the MySQL Server. (Bug #13979418)

     * Replication: An event whose length exceeded the size of the
       master dump thread's max_allowed_packet caused replication to
       fail. This could occur when updating many large rows and using
       row-based replication.
       As part of this fix, a new server option
       --slave-max-allowed-packet is added, which permits
       max_allowed_packet to be exceeded by the slave SQL and I/O
       threads. Now the size of a packet transmitted from the master
       to the slave is checked only against this value (available as
       the value of the slave_max_allowed_packet server system
       variable), and not against the value of max_allowed_packet.
       (Bug #12400221, Bug #60926)

     * Replication: Statements using AUTO_INCREMENT,
       LAST_INSERT_ID(), RAND(), or user variables could be applied
       in the wrong context on the slave when using statement-based
       replication and replication filtering server options (see How
       Servers Evaluate Replication Filtering Rules
       )). (Bug #11761686, Bug #54201)
       References: See also Bug #11754117, Bug #45670, Bug #11746146,
       Bug #23894.

     * Replication: An INSERT into a table that has a composite
       primary key that includes an AUTO_INCREMENT column that is not
       the first column of this composite key is not safe for
       statement-based binary logging or replication. Such statements
       are now marked as unsafe and fail with an error when using the
       STATEMENT binary logging format. For more information, see
       Determination of Safe and Unsafe Statements in Binary Logging
       nsafe.html), as well as Replication and AUTO_INCREMENT
       Tables using the InnoDB storage engine are not affected by
       this issue, since InnoDB does not allow the creation of a
       composite key that includes an AUTO_INCREMENT column, where
       this column is not the first column in the key.
       (Bug #11754117, Bug #45670)
       References: See also Bug #11761686, Bug #54201, Bug #11746146,
       Bug #23894.

     * Replication: After upgrading a replication slave to MySQL
       5.5.60 or later, enabling the query cache eventually caused
       the slave to fail. (Bug #64624, Bug #14005409)

     * Incorrect stored program caching could cause statements within
       a stored program that included a GROUP BY clause to return
       different results across multiple program invocations. (Bug

     * For queries with ORDER BY COUNT(*) and LIMIT, the optimizer
       could choose an execution plan that produced incorrect
       results. (Bug #12713907)

     * SHOW TABLES was very slow unless the required information was
       already in the disk cache. (Bug #60961, Bug #12427262)

     * mysqlbinlog exited with no error code if file write errors
       occurred. (Bug #55289, Bug #11762667)

     * yaSSL rejected valid SSL certificates that OpenSSL accepts.
       (Bug #54348, Bug #11761822)

     * Sessions could end up deadlocked when executing a combination
       (Bug #60682, Bug #12636001)

On Behalf of Oracle MySQL RE Team

Bjorn Munch
MySQL Release Engineer

Options: ReplyQuote

Written By
MySQL Community Server 5.1.65 has been released
August 09, 2012 01:21AM

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.