MySQL Server 5.1 is available on the following new platforms starting with the 5.1.42 release:
Mac OS X 10.6 x86/x64
HP-UX 11.31 IA64
SLES 11 x86/x64
InnoDB Plugin has been upgraded to version
1.0.6. This version is considered of Release Candidate (RC)
quality. InnoDB Storage Engine Change History, may contain
information in addition to those changes reported here.
In this release, the
InnoDB Plugin is
included in source and binary distributions, except RHEL3,
RHEL4, SuSE 9 (x86, x86_64, ia64), and generic Linux RPM
packages. It also does not work for FreeBSD 6 and HP-UX or for
Linux on S/390, PowerPC, and generic ia64.
When the query cache is fragmented, the size of the free block
lists in the memory bins grows, which causes query cache
invalidation to become slow. There is now a 50ms timeout for a
SELECT statement waiting for the
query cache lock. If the timeout expires, the statement executes
without using the query cache.
References: See also Bug #21074.
Important Change; Replication: The following functions have been marked unsafe for statement-based replication:
None of the functions just listed are guaranteed to replicate
correctly when using the statement-based format because they can
produce different results on the master and the slave. The use
of any of these functions while
binlog_format is set to
STATEMENT is logged with the warning,
Statement is not safe to log in statement
binlog_format is set to
MIXED, the binary logging format is
automatically switched to the row-based format whenever one of
these functions is used.
After a binary upgrade to MySQL 5.1 from a MySQL 5.0
installation that contains
In either case, the solution is to use
mysqldump to dump all 5.0
ARCHIVE tables before upgrading,
and reload them into MySQL 5.1 after upgrading. The same problem
occurs for binary downgrades from MySQL 5.1 to 5.0.
Partitioning: In some cases, it was not possible to add a new column to a table that had subpartitions. (Bug #48276)
References: This bug was introduced by Bug #45807.
SUBPARTITION BY KEY failed with
With row-based binary logging, the server crashed for statements
of the form
CREATE TABLE IF NOT EXISTS
occurred because the server handled the existing view as a table
when logging the statement.
When using row-based logging,
TABLE was written to the binary log even if the
affected table was temporary, causing replication to fail.
References: See also Bug #38850, Bug #43783, Bug #43785, Bug #47741, Bug #48091.
When using row-based format, replication failed with the error
Could not execute Write_rows event on table ...;
Field '...' doesn't have a default value when an
INSERT was made on the master
without specifying a value for a column having no default, even
if strict server SQL mode was not in use and the statement would
otherwise have succeeded on the master. Now the SQL mode is
checked, and the statement is replicated unless strict mode is
in effect. For more information, see Server SQL Modes.
References: See also Bug #38262, Bug #43992.
Incorrect cache initialization prevented storage of converted constant values and could produce incorrect comparison results. (Bug #49489)
could produce incorrect results.
References: See also Bug #43668.
Privileges for stored routines were ignored for mixed-case routine names. (Bug #48872)
References: See also Bug #41049.
Building MySQL on Fedora Core 12 64-bit failed, due to errors in comp_err. (Bug #48864)
INTERVAL expressions could cause a
crash on 64-bit systems.
During query execution, ranges could be merged incorrectly for
OR operations and return an
DISTINCT was ignored for queries with
GROUP BY WITH ROLLUP and only
Loose index scan was inappropriately chosen for some
The server could crash and corrupt the tablespace if the
InnoDB tablespace was configured
with too small a value, or if
enabled and many
TABLE statements were executed and the temporary file
directory filled up.
Parts of the range optimizer could be initialized incorrectly, resulting in Valgrind errors. (Bug #48459)
A bad typecast could cause query execution to allocate large amounts of memory. (Bug #48458)
InnoDB could not be
built as a statically linked library.
mysql_secure_installation did not work on Solaris. (Bug #48086)
When running mysql_secure_installation, the
command failed if the
root password contained
or quote characters.
MATCH IN BOOLEAN MODE searches could return
too many results inside a subquery.
If a session acquired a global read lock with
FLUSH TABLES WITH READ
LOCK, acquired a lock for one table with
LOCK TABLES, and issued an
INSERT DELAYED statement for
another table, deadlock could occur.
The mysql client
command displayed an incorrect value for the server character
Connecting to a 4.1.x server from a 5.1.x or higher mysql client resulted in a memory-free error when disconnecting. (Bug #47655)
Assignment of a system variable sharing the same base name as a declared stored program variable in the same context could lead to a crash. (Bug #47627)
mysqladmin debug could crash on 64-bit systems. (Bug #47382)
system variable could not be set at runtime to
DEFAULT or to the value of a user-defined
The Mac OS X MySQL Preference Pane component was not built for 64-bit, which would trigger the System Preferences application to restart into 32-bit mode. (Bug #46935)
IGNORE clause on a
DELETE statement masked an SQL
statement error that occurred during trigger processing.
Valgrind errors for
InnoDB Plugin were
(Bug #45992, Bug #46656)
The return value was not checked for some
References: See also Bug #48370.
The server could crash when attempting to access a
mysql.proc system table. For
example, the server could crash when invoking stored
procedure-related statements after an upgrade from MySQL 5.0 to
5.1 without running mysql_upgrade.
Multiple-statement execution could fail. (Bug #40877)
SHOW ENGINE INNODB
STATUS or one of the
InnoDB Monitor tables) could cause
a server crash due to invalid access to a shared variable in a
concurrent environment. This is a further fix for a regression
introduced in MySQL 5.1.38 to the original fix in MySQL 5.1.31.
On Windows, the mysql_secure_installation
command failed to load the
module, which was required for correct operation.
--log-bin server option
was set to a directory name with a trailing component separator
character, the basename of the binary log files was empty, so
that the created files were named
.index. The same thing occurred with
--relay-log-index options. Now
the server reports and error and exits.
If a comparison involved a constant value that required type conversion, the converted value might not be cached, resulting in repeated conversion and poorer performance. (Bug #34384)
ENGINE INNODB STATUS statement when using partitions
InnoDB tables caused
(old?) table or database name errors to be logged.
On some Windows systems,
InnoDB could report
Operating system error number 995 in a file
operation due to transient driver or hardware
InnoDB now retries the operation
Retry attempt is made to the error