Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Timothy Smith (Timothy.SmithSun.COM)
Date: Thu Jun 04 2009 - 14:27:34 CDT
Dear MySQL users,
MySQL Community Server 5.1.35, a new version of the popular Open
Source Database Management System, has been released. MySQL 5.1.35 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.35 on new servers or upgrading
to MySQL 5.1.35 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,
For information on open issues in MySQL 5.1, please see the errata
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
The MySQL build team at Sun Microsystems
This release of MySQL has two known outstanding issues for
* The .msi installer does not detect an existing root password
on the initial configuration attempt. To work around this,
install and configure MySQL as normal, but skip any changes to
security. (There is a checkbox that allows this on the
security screen of the configuration wizard.) Then check your
+ If the old root password and security settings are okay,
you are done and can proceed to use MySQL.
+ Otherwise, reconfigure with the wizard and make any
changes on the second configuration attempt. The wizard
will properly prompt for the existing root password and
allow changes to be made.
This issue has been filed as
Bug#45200: http://bugs.mysql.com/45200 for correction in a
* The Windows configuration wizard allows changes to InnoDB
settings during a reconfiguration operation. For an upgrade,
this may cause difficulties. To work around this, use one of
the following alternatives:
+ Do not change InnoDB settings.
+ Copy files from the old InnoDB location to the new one.
This issue has been filed as
Bug#45201: http://bugs.mysql.com/45201 for correction in a
* Important Change: Replication: The transactional behavior of
STOP SLAVE has changed. Formerly, it took effect immediately,
even inside a transaction; now, it waits until the current
replication event group (if any) has finished executing, or
until the user issues a KILL QUERY or KILL CONNECTION
This was done in order to solve the problem encountered when
replication was stopped while a nontransactional slave was
replicating a transaction on the master. (It was impossible to
roll back a mixed-engines transaction when one of the engines
was nontransactional, which meant that the slave could not
safely re-apply any transaction that had been interrupted by
STOP SLAVE.) (Bug#319: http://bugs.mysql.com/319,
See also Bug#43217: http://bugs.mysql.com/43217.
* Partitioning: When a value was equal to a PARTITION ... VALUES
LESS THAN (value) value other than MAXVALUE, the corresponding
partition was not pruned.
* Replication: Unrelated errors occurring during the execution
of RESET SLAVE could cause the slave to crash.
* Replication: The --slave-skip-errors option had no effect when
using row-based logging format.
* Replication: The following erors were not correctly reported:
+ Failures during slave thread initialization
+ Failures while initializing the relay log position
(immediately following the starting of the slave thread)
+ Failures while processing queries passed through the
Information about these types of failures can now be found in
the output of SHOW SLAVE STATUS.
* Replication: Killing the thread executing a DDL statement,
after it had finished its execution but before it had written
the binlog event, caused the error code in the binlog event to
be set (incorrectly) to ER_SERVER_SHUTDOWN or
ER_QUERY_INTERRUPTED, which caused replication to fail.
See also Bug#27571: http://bugs.mysql.com/27571,
* Replication: Column alises used inside subqueries were ignored
in the binary log. (Bug#35515: http://bugs.mysql.com/35515)
* Valgrind warnings for the DECODE(), ENCRYPT(), and
FIND_IN_SET() functions were corrected.
* On Windows, entries for build-vs9.bat and build-vs9_x64.bat
were missing in win/Makefile.am.
* Incomplete cleanup of JOIN_TAB::select during the filesort of
rows for a GROUP BY clause inside a subquery caused a server
crash. (Bug#44290: http://bugs.mysql.com/44290)
* Not all lock types had proper descriptive strings, resulting
in garbage output from mysqladmin debug.
* Use of HANDLER statements with INFORMATION_SCHEMA tables
caused a server crash. Now HANDLER is prohibited with such
tables. (Bug#44151: http://bugs.mysql.com/44151)
* Invoking SHOW TABLE STATUS from within a stored procedure
could cause a Packets out of order error.
* myisamchk could display a negative Max keyfile length value.
* On 64-bit systems, a key_buffer_size value larger than 4GB
could couse MyISAM index corruption.
* mysqld_multi incorrectly passed --no-defaults to mysqld_safe.
* SHOW VARIABLES did not properly display the value of
slave_skip_errors. (Bug#43835: http://bugs.mysql.com/43835)
* On Windows, a server crash occurred for attempts to insert a
floating-point value into a CHAR column with a maximum length
less than the converted floating-point value length.
* Incorrect initialization of MyISAM table indexes could cause
incorrect query results.
* libmysqld crashed when it was reinitialized.
* InnoDB uses random numbers to generate dives into indexes for
calculating index cardinality. However, under certain
conditions, the algorithm did not generate random numbers, so
ANALYZE TABLE did not update cardinality estimates properly. A
new algorithm has been introduced with better randomization
properties, together with a system variable,
innodb_use_legacy_cardinality_algorithm, that controls which
algorithm to use. The default value of the variable is 1 (ON),
to use the original algorithm for compatibility with existing
applications. The variable can be set to 0 (OFF) to use the
new algorithm with improved randomness.
* UNION of floating-point numbers did unnecessary rounding.
* ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME failed when the
database contained views.
* Certain statements might open a table and then wait for an
impending global read lock without noticing whether they hold
a table being waiting for by the global read lock, causing a
hang. Affected statements are SELECT ... FOR UPDATE, LOCK
TABLES ... WRITE, TRUNCATE TABLE, and LOAD DATA INFILE.
* Using an XML function such as ExtractValue() more than once in
a single query could produce erroneous results.
See also Bug#43937: http://bugs.mysql.com/43937.
* Full-text prefix searches could hang the connection and cause
100% CPU consumption. (Bug#42907: http://bugs.mysql.com/42907)
* InnoDB had excessive contention for a character set mutex.
* Incorrect elevation of warning messages to error messages for
unsafe statements caused a server crash.
* CHECK TABLE suggested use of REPAIR TABLE for corrupt tables
for storage engines not supported by REPAIR TABLE. Now CHECK
TABLE suggests that the user dump and reload the table.
* Compressing a table with the myisampack utility caused the
server to produce Valgrind warnings when it opened the table.
* For a MyISAM table with DELAY_KEY_WRITE enabled, the index
file could be corrupted without the table being marked as
crashed if the server was killed.
* Killing an INSERT ... SELECT statement for a MyISAM table
could cause table corruption if the table had indexes.
* A multiple-table DELETE IGNORE statement involving a foreign
key constraint caused an assertion failure.
* Multiple-table UPDATE statements did not properly activate
triggers. (Bug#39953: http://bugs.mysql.com/39953)
* The mysql_setpermission operation for removing database
privileges removed global privileges instead.
* A stored routine contain a C-style comment could not be dumped
and reloaded. (Bug#39559: http://bugs.mysql.com/39559)
* In an UPDATE or DELETE via a secondary index, InnoDB did not
store the cursor position. This made InnoDB crash in
semi-consistent read while attempting to unlock a nonmatching
record. (Bug#39320: http://bugs.mysql.com/39320)
* The functions listed in Section 188.8.131.52.3, "Creating
Geometry Values Using MySQL-Specific Functions," previously
accepted WKB arguments and returned WKB values. They now
accept WKB or geometry arguments and return geometry values.
The functions listed in Section 184.108.40.206.2, "Creating
Geometry Values Using WKB Functions," previously accepted WKB
arguments and returned geometry values. They now accept WKB or
geometry arguments and return geometry values.
* On WIndows, running the server with myisam_use_mmap enabled
caused MyISAM table corruption.
* CHECK TABLE did not properly check whether MyISAM tables
created by servers from MySQL 4.0 or older needed to be
upgraded. This could cause problems upgrading to MySQL 5.1 or
higher. (Bug#37631: http://bugs.mysql.com/37631)
* An UPDATE statement that updated a column using the same
DES_ENCRYPT() value for each row actually updated different
rows with different values.
* For shared-memory connections, the read and write methods did
not properly handle asynchronous close events, which could
lead to the client locking up waiting for a server response.
For example, a call to mysql_real_query() would block forever
on the client side if the executed statement was aborted on
the server side. Thanks to Armin Schöffmann for the bug report
and patch. (Bug#33899: http://bugs.mysql.com/33899)
* CHECKSUM TABLE was not killable with KILL QUERY.
* myisamchk and myisampack were not being linked with the
library that enabled support for * filename pattern expansion.
* For InnoDB tables that have their own .ibd tablespace file, a
superfluous ibuf cursor restoration fails! message could be
written to the error log. This warning has been suppressed.
* COMMIT did not delete savepoints if there were no changes in
the transaction. (Bug#26288: http://bugs.mysql.com/26288)
* Several memory allocation functions were not being checked for
out-of-memory return values.
Timothy Smith, Product Engineering, MySQL
Database Technology Group, Sun Microsystems
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce