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: Sun Aug 02 2009 - 15:06:03 CDT
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,
For information on open issues in MySQL 5.1, please see the errata
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
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: http://bugs.mysql.com/44270)
See also Bug#34654: http://bugs.mysql.com/34654.
* 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:
DROP TABLE IF EXISTS t1;
SET SESSION SQL_MODE='ONLY_FULL_GROUP_BY';
CREATE TABLE t1(id INT, key(id))
PARTITION BY HASH(id) PARTITIONS 2;
* 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:
ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK, and ER_XA_RBDEADLOCK.
* 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
See also Bug#43076: http://bugs.mysql.com/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: http://bugs.mysql.com/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: http://bugs.mysql.com/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
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: http://bugs.mysql.com/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: http://bugs.mysql.com/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: http://bugs.mysql.com/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: http://bugs.mysql.com/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() (ha_myisammrg.cc:546)
by: ha_myisammrg::extra(ha_extra_function) (ha_myisammrg.cc:944)
by: attach_merge_children(TABLE_LIST*) (sql_base.cc:4147)
by: open_tables(THD*, TABLE_LIST**, unsigned*, unsigned) (sql_base.cc
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_execute_command(THD*) (sql_parse.cc:2860)
by: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse
by: dispatch_command (sql_parse.cc:1213)
* 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: http://bugs.mysql.com/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: http://bugs.mysql.com/45412)
* An assertion failure could occur if InnoDB tried to unlock a
record when the clustered index record was unknown.
* Bug#19027: http://bugs.mysql.com/19027 caused
--enable-plugin_name (for example, --enable-innodb) not to
work. (Bug#45336: http://bugs.mysql.com/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: http://bugs.mysql.com/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: http://bugs.mysql.com/45168)
* InnoDB recovery could hang due to redo logging of doublewrite
buffer pages. (Bug#45097: http://bugs.mysql.com/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 * FROM (SELECT 1) AS t1,
(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:
SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM ...
* configure.in contained references to literal instances of nm
and libc, rather than to variables parameterized for the
proper values on the current platform.
* configure.in did not properly check for the
* 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: http://bugs.mysql.com/21704)
Timothy Smith, Release Engineering, MySQL
Database Technology Group, Sun Microsystems
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce