The “-m3″ suffix indicates that these releases belong to the third milestone, also called “Celosia”.

You can read more about the release model and the planned milestones at  http://forge.mysql.com/wiki/Development_Cycle

The new features in these releases are of beta quality. As with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data.

Please note that *downgrading* from these releases to a previous release series, including MySQL Server 5.5 milestone 2 (Betony) releases, is not supported.

MySQL 5.5 is based on MySQL 5.4, which won’t get any further updates.

MySQL 5.5 includes several high-impact changes to address scalability and performance issues in MySQL Server. These changes exploit advances in hardware and CPU design and enable better utilization of existing

hardware.

For an overview of what’s new in MySQL 5.5, please see the section “What Is New in MySQL 5.5″ online at  http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

For information on installing MySQL 5.5.5-m3 on new servers, please see the MySQL installation documentation at  http://dev.mysql.com/doc/refman/5.5/en/installing.html

For upgrading from previous MySQL releases, please see the important upgrade considerations at

http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html <http://dev.mysql.com/doc/refman/5.5/en/installing.html>

MySQL Server 5.5 is available in source and binary form for a number of platforms from the “Development Releases” selection of download pages at

http://dev.mysql.com/downloads/mysql/

The complete list of all “Bugs Fixed” may be viewed online at  http://dev.mysql.com/doc/refman/5.5/en/news-5-5-5.html

Special note for those of you who build from source:

In MySQL 5.5.5-m3, CMake joins GNU autotools as a build framework for all platforms. Existing support for GNU autotools isn’t going away just yet, but if you are so inclined, you can now alternatively use CMake as per the

instructions on the web page linked below. The official packages for this release are the first to be produced using CMake.

http://forge.mysql.com/wiki/CMake

Changes in MySQL 5.5.5:

|InnoDB is now the default storage engine, rather than MyISAM in|||  the regular versions of MySQL. This change has the following consequences:

* Existing tables are not affected by this change, only new tables that are created.

* Some of the|InnoDB|  option settings also change, so that the default configuration represents the best practices for|InnoDB|

functionality,reliability, and file management:

|innodb_file_format=Barracuda|  rather than|Antelope|,

|innodb_strict_mode=TRUE|  rather than|FALSE|, and

|innodb_file_per_table=TRUE|  rather than|FALSE|.

* The system tables remain in|MyISAM|  format.

*|MyISAM|  remains the default storage engine for the embedded version of MySQL

Bugs Fixed:

* Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full

row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be preferred, making full

table scans less likely.

(Bug#39653:http://bugs.mysql.com/bug.php?id=39653)

* Security Fix: The server failed to check the table name argument of a COM_FIELD_LIST command packet for validity and

compliance to acceptable table name standards. This could be exploited to bypass almost all forms of checks for privileges

and table-level grants by providing a specially crafted table name argument to COM_FIELD_LIST.

In MySQL 5.0 and above, this allowed an authenticated user with SELECT privileges on one table to obtain the field

definitions of any table in all other databases and potentially of other MySQL instances accessible from the

server’s file system.

Additionally, for MySQL version 5.1 and above, an authenticated user with DELETE or SELECT privileges on one

table could delete or read content from any other table in all databases on this server, and potentially of other MySQL

instances accessible from the server’s file system.

(Bug#53371:http://bugs.mysql.com/bug.php?id=53371,

CVE-2010-1848 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1848))

* Security Fix: The server was susceptible to a buffer-overflow attack due to a failure to perform bounds checking on the

table name argument of a COM_FIELD_LIST command packet. By sending long data for the table name, a buffer is overflown,

which could be exploited by an authenticated user to inject malicious code.

(Bug#53237:http://bugs.mysql.com/bug.php?id=53237,

CVE-2010-1850 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1850))

* Security Fix: Privilege checking for UNINSTALL PLUGIN was incorrect. (Bug#51770:http://bugs.mysql.com/bug.php?id=51770,

CVE-2010-1621 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1621))

* Security Fix: The server could be tricked into reading packets indefinitely if it received a packet larger than the maximum

size of one packet.

(Bug#50974:http://bugs.mysql.com/bug.php?id=50974,

CVE-2010-1849 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1849))

* Incompatible Change: TRUNCATE TABLE did not take an exclusive lock on a table if truncation was done by deleting all rows in

the table. For InnoDB tables, this could break proper isolation because InnoDB ended up aborting some granted locks

when truncating a table. Now an exclusive metadata lock is taken before TRUNCATE TABLE can proceed. This guarantees that

no other transaction is using the table.

Incompatible change: Truncation using delete no longer fails if sql_safe_updates is enabled (this was an undocumented side

effect). (Bug#42643:http://bugs.mysql.com/bug.php?id=42643)

* Important Change: Replication: It was possible to set sql_log_bin with session scope inside a transaction or

subquery. (Bug#53437:http://bugs.mysql.com/bug.php?id=53437)

* Important Change: Replication: When changing binlog_format or binlog_direct_non_transactional_updates, permissions were not

checked prior to checking the scope and context of the variable being changed.

As a result of this fix, an error is no longer reported when—in the context of a transaction or a stored

function—you try to set a value for a session variable that is the same as its previous value, or for a variable whose

scope is global only.

(Bug#51277:http://bugs.mysql.com/bug.php?id=51277)

* Important Change: Replication: When invoked, CHANGE MASTER TO and SET GLOBAL sql_slave_skip_counter now cause information to

be written to the error log about the slave’s state prior to execution of the statement. For CHANGE MASTER TO, this

information includes the previous values for MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET

GLOBAL sql_slave_skip_counter, this information includes the previous values of sql_slave_skip_counter, the group relay log

name, and the group relay log position.

(Bug#43406:http://bugs.mysql.com/bug.php?id=43406,

Bug#43407:http://bugs.mysql.com/bug.php?id=43407)

* Partitioning: Replication: Attempting to execute LOAD DATA on a partitioned MyISAM table while using statement-based logging

mode caused the master to hang or crash.

(Bug#51851:http://bugs.mysql.com/bug.php?id=51851)

* Partitioning: Replication: The NO_DIR_IN_CREATE server SQL mode was not enforced when defining subpartitions. In certain

cases, this could lead to failures on replication slaves.

(Bug#42954:http://bugs.mysql.com/bug.php?id=42954)

* Partitioning: Rows inserted into a table created using a PARTITION BY LIST COLUMNS option referencing multiple columns

could be inserted into the wrong partition.

(Bug#52815:http://bugs.mysql.com/bug.php?id=52815)

* Partitioning: Partition pruning on RANGE partitioned tables did not always work correctly; the last partition was not

excluded if the range was beyond it (when not using MAXVALUE).

Now the last partition is not included if the partitioning function value is not within the range.

(Bug#51830:http://bugs.mysql.com/bug.php?id=51830)

* Partitioning: Attempting to partition a table using a DECIMAL column caused the server to crash; this not supported and is

now specifically disallowed.

Bug#51347:http://bugs.mysql.com/bug.php?id=51347)

* Partitioning: ALTER TABLE statements that cause table partitions to be renamed or dropped (such as ALTER TABLE …

ADD PARTITION, ALTER TABLE … DROP PARTITION, and ALTER TABLE … REORGANIZE PARTITION) — when run concurrently with

queries against the INFORMATION_SCHEMA.PARTITIONS table —

could fail, cause the affected partitioned tables to become unusable, or both. This was due to the fact that the

INFORMATION_SCHEMA database ignored the name lock imposed by the ALTER TABLE statement on the partitions affected. In

particular, this led to problems with InnoDB tables, because InnoDB would accept the rename operation, but put it in a

background queue, so that subsequent rename operations failed when InnoDB was unable to find the correct partition. Now,

INFORMATION_SCHEMA honors name locks imposed by ongoing ALTER TABLE statements that cause partitions to be renamed or

dropped. (Bug#50561:http://bugs.mysql.com/bug.php?id=50561)

See also Bug#47343:http://bugs.mysql.com/bug.php?id=47343,

Bug#45808:http://bugs.mysql.com/bug.php?id=45808.

* Partitioning: The insert_id server system variable was not reset following an insert that failed on a partitioned MyISAM

table having an AUTO_INCREMENT column.

(Bug#50392:http://bugs.mysql.com/bug.php?id=50392)

* Partitioning: Foreign keys are not supported on partitioned tables. However, it was possible via an ALTER TABLE statement

to set a foreign key on a partitioned table; it was also possible to partition a table with a single foreign key.

(Bug#50104:http://bugs.mysql.com/bug.php?id=50104)

* Partitioning: When attempting to perform DDL on a partitioned table and the table’s .par file could not be found, the server

returned the inaccurate error message Out of memory; restart server and try again (needed 2 bytes). Now in such cases, the

server returns the error Failed to initialize partitions from .par file. (Bug#49161:http://bugs.mysql.com/bug.php?id=49161)

* Partitioning: GROUP BY queries performed poorly for some partitioned tables. This was due to the block size not being

set for partitioned tables, thus the keys per block was not correct, which could cause such queries to be optimized

incorrectly.

(Bug#48229:http://bugs.mysql.com/bug.php?id=48229)

See also Bug#37252:http://bugs.mysql.com/bug.php?id=37252.

* Partitioning: REPAIR TABLE failed for partitioned ARCHIVE tables. (Bug#46565:http://bugs.mysql.com/bug.php?id=46565)

* Replication: When using unique keys on NULL columns in row-based replication, the slave sometimes chose the wrong row

when performing an update. This happened because a table having a unique key on such a column could have multiple rows

containing NULL for the column used by the unique key, and the slave merely picked the first row containing NULL in that

column. (Bug#53893:http://bugs.mysql.com/bug.php?id=53893)

* Replication: When a CREATE TEMPORARY TABLE … SELECT statement was executed within a transaction that updated only

transactional engines and was later rolled back (for example, due to a deadlock) the changes—including the creation of the

temporary table—were not written to the binary log, which caused subsequent updates to this table to fail on the slave.

(Bug#53421:http://bugs.mysql.com/bug.php?id=53421)

* Replication: When using the statement-based logging format, statements that used CONNECTION_ID() were always kept in the

transaction cache; consequently, nontransactional changes that should have been flushed before the transaction were kept in

the transaction cache.

(Bug#53075:http://bugs.mysql.com/bug.php?id=53075)

This regression was introduced by

Bug#51894:http://bugs.mysql.com/bug.php?id=51894.

* Replication: In some cases, attempting to update a column with a value of an incompatible type resulted in a mismatch between

master and slave because the column value was set to its implicit default value on the master (as expected), but the

same column on the slave was set to NULL.

(Bug#52868:http://bugs.mysql.com/bug.php?id=52868)

* Replication: When temporary tables were in use, switching the binary logging format from STATEMENT to ROW did not take

effect until all temporary tables were dropped. (The existence of temporary tables should prevent switching the format only

from ROW to STATEMENT from taking effect, not the reverse.)

(Bug#52616:http://bugs.mysql.com/bug.php?id=52616)

* Replication: A buffer overrun in the handling of DATE column values could cause mysqlbinlog to fail when reading back logs

containing certain combinations of DML on a table having a DATE column followed by dropping the table.

(Bug#52202:http://bugs.mysql.com/bug.php?id=52202)

* Replication: The failure of a REVOKE statement was logged with the wrong error code, causing replication slaves to stop even

when the failure was expected on the master.

(Bug#51987:http://bugs.mysql.com/bug.php?id=51987)

* -laio missing from embedded libs (Bug#55215:_http://bugs.mysql.com/bug.php?id=55215_)

Please see the complete list of changes to MySQL 5.5.5 at http://dev.mysql.com/doc/refman/5.5/en/news-5-5-5.html

What Is New in MySQL 5.5

The following features have been added to MySQL 5.5:

* Support for an interface for semisynchronous replication:
A commit performed on the master side blocks before returning
to the session that performed the transaction until at least
one slave acknowledges that it has received and logged the events
for the transaction.
Semisynchronous replication is implemented through an optional
plugin component. See Section 16.2.8, “Semisynchronous Replication”

* Support for the SQL standard SIGNAL and RESIGNAL statements.
See Section 12.8.8, “SIGNAL and RESIGNAL”.

* Enhancements to XML functionality, including a new LOAD XML
statement.

* Two new types of user-defined partitioning are supported:
RANGE COLUMNS partitioning is an extension to RANGE partitioning;
LIST COLUMNS partitioning is an extension to LIST partitioning.
Each of these extensions provides two enhancements to MySQL
partitioning capabilities:

1. It is possible to define partitioning ranges or lists based on
DATE, DATETIME, or string values (such as CHAR or VARCHAR).

You can also define ranges or lists based on multiple column
values when partitioning tables by RANGE COLUMNS or LIST COLUMNS,
respectively. Such a range or list may refer to up to 16 columns.

2. For tables defined using these partitioning types, partition
pruning can now optimize queries with WHERE conditions that use
multiple comparisons between (different) column values and
constants, such as
a = 10 AND b > 5 or a < “2005-11-25″ AND b = 10 AND c = 50.

For more information, see Section 17.2.1, “RANGE Partitioning”,
and Section 17.2.2, “LIST Partitioning”.

* It is now possible to delete all rows from one or more partitions
of a partitioned table using the ALTER TABLE … TRUNCATE
PARTITION statement. Executing the statement deletes rows without
affecting the structure of the table. The partitions named in the
TRUNCATE PARTITION clause do not have to be contiguous.

* Key caches are now supported for indexes on partitioned MyISAM
tables, using the CACHE INDEX and LOAD INDEX INTO CACHE statements.
In addition, a key cache can be defined for and loaded with indexes
from an entire partitioned table, or for one or more partitions.
In the latter case, the partitions are not required to be contiguous.

* The TO_SECONDS() function is added. This function converts a date or
datetime expression to a number of seconds since the year 0. You may
use this function in partitioning expressions, and partition pruning
is supported for table defined using such expressions.

The following constructs are deprecated and will be removed in a future MySQL release. Where alternatives are shown, applications should be updated to use them.

* The table_type system variable (use storage_engine).

The TYPE table option to specify the storage engine for
CREATE TABLE or ALTER TABLE (use ENGINE).

The SHOW TABLE TYPES SQL statement (use SHOW ENGINES).

* The log_bin_trust_routine_creators variable
(use log_bin_trust_function_creators).

* TIMESTAMP(N): The ability to specify a display width of N
(use without N).

* The SHOW INNODB STATUS and SHOW MUTEX STATUS SQL statements
(use SHOW ENGINE INNODB STATUS for both of these).

* The LOAD TABLE … FROM MASTER and LOAD DATA FROM MASTER SQL
statements.

* The SHOW PLUGIN SQL statement (use SHOW PLUGINS).

* The BACKUP TABLE and the RESTORE TABLE SQL statements.

* The –master-xxx server options to set replication parameters
(use the CHANGE MASTER TO statement instead):
–master-host, –master-user, –master-password, –master-port,
–master-connect-retry, –master-ssl, –master-ssl-ca,
–master-ssl-capath, –master-ssl-cert, –master-ssl-cipher,
–master-ssl-key.

—–

Changes in MySQL 5.5.2:

InnoDB Plugin Notes:

* This release includes InnoDB Plugin 1.0.6. This version is
considered of Release Candidate (RC) quality.

Functionality added or changed:

* Replication: Introduced the
–binlog-direct-non-transactional-updates server option. This
option causes updates using the statement-based logging format
to tables using non-transactional engines to be written
directly to the binary log, rather than to the transaction
cache.
Before using this option, be certain that you have no
dependencies between transactional and non-transactional
tables. A statement that both selects from an InnoDB table and
inserts into a MyISAM table is an example of such a
dependency. For more information, see Section 16.1.3.4,
“Binary Log Options and Variables.”
(Bug#46364: http://bugs.mysql.com/bug.php?id=46364)
See also Bug#28976: http://bugs.mysql.com/bug.php?id=28976,
Bug#40116: http://bugs.mysql.com/bug.php?id=40116.

Bugs fixed:

* Performance: The method for comparing INFORMATION_SCHEMA names
and database names was nonoptimal and an improvement was made:
When the database name length is already known, a length check
is made first and content comparison skipped if the lengths
are unequal.
(Bug#49501: http://bugs.mysql.com/bug.php?id=49501)

* Performance: The MD5() and SHA1() functions had excessive
overhead for short strings.
(Bug#49491: http://bugs.mysql.com/bug.php?id=49491)

* Security Fix: For servers built with yaSSL, a preauthorization
buffer overflow could cause memory corruption or a server
crash. We thank Evgeny Legerov from Intevydis for providing us
with a proof-of-concept script that allowed us to reproduce
this bug. (Bug#50227: http://bugs.mysql.com/bug.php?id=50227,
CVE-2009-4484
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4484))

* Incompatible Change: In plugin.h, the MYSQL_REPLICATION_PLUGIN
symbol was out of synchrony with its value in MySQL 6.0
because the lower-valued MYSQL_AUDIT_PLUGIN was not present.
To correct this, MYSQL_AUDIT_PLUGIN has been added in MySQL
5.5, changing the value of MYSQL_REPLICATION_PLUGIN from 5 to

6. Attempts to load the audit plugin produce an error occurs
because only the MYSQL_AUDIT_PLUGIN symbol was added, not the
audit plugin itself. This error will go away when the audit
plugin is added to MySQL 5.5. Replication plugins from earlier
5.5.x releases must be recompiled against the current release
before they will work with the current release.
(Bug#49894: http://bugs.mysql.com/bug.php?id=49894)

* Important Change: Replication: The RAND() function is now
marked as unsafe for statement-based replication. Using this
function now generates a warning when binlog_format=STATEMENT
and causes the the format to switch to row-based logging when
binlog_format=MIXED.
This change is being introduced because, when RAND() was
logged in statement mode, the seed was also written to the
binary log, so the replication slave generated the same
sequence of random numbers as was generated on the master.
While this could make replication work in some cases, the
order of affected rows was still not guaranteed when this
function was used in statements that could update multiple
rows, such as UPDATE or INSERT … SELECT; if the master and
the slave retrieved rows in different order, they began to
diverge. (Bug#49222: http://bugs.mysql.com/bug.php?id=49222)

* Partitioning: When used on partitioned tables, the
records_in_range handler call checked all partitions, rather
than the unpruned partitions only.
(Bug#48846: http://bugs.mysql.com/bug.php?id=48846)
See also Bug#37252: http://bugs.mysql.com/bug.php?id=37252,
Bug#47261: http://bugs.mysql.com/bug.php?id=47261.

* Partitioning: When an ALTER TABLE … REORGANIZE PARTITION
statement on an InnoDB table failed due to
innodb_lock_wait_timeout expiring while waiting for a lock,
InnoDB did not clean up any temporary files or tables which it
had created. Attempting to reissue the ALTER TABLE statement
following the timeout could lead to storage engine errors, or
possibly a crash of the server.
(Bug#47343: http://bugs.mysql.com/bug.php?id=47343)

* Replication: FLUSH LOGS could in some circumstances crash the
server. This occurred because the I/O thread could
concurrently access the relay log I/O cache while another
thread was performing the FLUSH LOGS, which closes and reopens
the relay log and, while doing so, initializes (or
re-initializes) its I/O cache. This could cause problems if
some other thread (in this case, the I/O thread) is accessing
it at the same time.
Now the thread performing the FLUSH LOGS takes a lock on the
relay log before actually flushing it.
(Bug#50364: http://bugs.mysql.com/bug.php?id=50364)

* Replication: With semisynchronous replication, memory
allocated for handling transactions could be freed while still
in use, resulting in a server crash.
(Bug#50157: http://bugs.mysql.com/bug.php?id=50157)

* Replication: In some cases, inserting into a table with many
columns could cause the binary log to become corrupted.
(Bug#50018: http://bugs.mysql.com/bug.php?id=50018)
See also Bug#42749: http://bugs.mysql.com/bug.php?id=42749.

* Replication: When using row-based replication, setting a BIT
or CHAR column of a MyISAM table to NULL, then trying to
delete from the table, caused the slave to fail with the error
Can’t find record in table.
(Bug#49481: http://bugs.mysql.com/bug.php?id=49481,
Bug#49482: http://bugs.mysql.com/bug.php?id=49482)

* Replication: A LOAD DATA INFILE statement that loaded data
into a table having a column name that had to be escaped (such
as `key` INT) caused replication to fail when logging in mixed
or statement mode. In such cases, the master wrote the LOAD
DATA event into the binary log without escaping the column
names. (Bug#49479: http://bugs.mysql.com/bug.php?id=49479)
See also Bug#47927: http://bugs.mysql.com/bug.php?id=47927.

* Replication: When logging in row-based mode, DDL statements
are actually logged as statements; however, statements that
affected temporary tables and followed DDL statements failed
to reset the binary log format to ROW, with the result that
these statements were logged using the statement-based format.
Now the state of binlog_format is restored after a DDL
statement has been written to the binary log.
(Bug#49132: http://bugs.mysql.com/bug.php?id=49132)

* Replication: Spatial data types caused row-based replication
to crash. (Bug#48776: http://bugs.mysql.com/bug.php?id=48776)

* Replication: When using row-based logging, the statement
CREATE TABLE t IF NOT EXIST … SELECT was logged as CREATE
TEMPORARY TABLE t IF NOT EXIST … SELECT when t already
existed as a temporary table. This was caused by the fact that
the temporary table was opened and the results of the SELECT
were inserted into it when a temporary table existed and had
the same name.
Now, when this statement is executed, t is created as a base
table, the results of the SELECT are inserted into it — even
if there already exists a temporary table having the same name
— and the statement is logged correctly.
(Bug#47418: http://bugs.mysql.com/bug.php?id=47418)
See also Bug#47442: http://bugs.mysql.com/bug.php?id=47442.

* Replication: Due to a change in the size of event
representations in the binary log, when replicating from a
MySQL 4.1 master to a slave running MySQL 5.0.60 or later, the
START SLAVE UNTIL statement did not function correctly,
stopping at the wrong position in the log. Now the slave
detects that the master is using the older version of the
binary log format, and corrects for the difference in event
size, so that the slave stops in the correct position.
(Bug#47142: http://bugs.mysql.com/bug.php?id=47142)

* Replication: Manually removing entries from the binary log
index file on a replication master could cause the server to
repeatedly send the same binary log file to slaves.
(Bug#28421: http://bugs.mysql.com/bug.php?id=28421)

* The SSL certificates in the test suite were about to expire.
They have been updated with expiration dates in the year 2015.
(Bug#50642: http://bugs.mysql.com/bug.php?id=50642)

* SPATIAL indexes were allowed on columns with non-spatial data
types, resulting in a server crash for subsequent table
inserts. (Bug#50574: http://bugs.mysql.com/bug.php?id=50574)

* Index prefixes could be specified with a length greater than
the associated column, resulting in a server crash for
subsequent table inserts.
(Bug#50542: http://bugs.mysql.com/bug.php?id=50542)

* Use of loose index scan optimization for an aggregate function
with DISTINCT (for example, COUNT(DISTINCT)) could produce
incorrect results.
(Bug#50539: http://bugs.mysql.com/bug.php?id=50539)

* The printstack function does not exist on Solaris 8 or
earlier, which would lead to a compilation failure.
(Bug#50409: http://bugs.mysql.com/bug.php?id=50409)

* A user could see tables in INFORMATION_SCHEMA.TABLES without
appropriate privileges for them.
(Bug#50276: http://bugs.mysql.com/bug.php?id=50276)

* Debug output for join structures was garbled.
(Bug#50271: http://bugs.mysql.com/bug.php?id=50271)

* Within a stored routine, selecting the result of CONCAT_WS()
with a routine parameter argument into a user variable could
return incorrect results.
(Bug#50096: http://bugs.mysql.com/bug.php?id=50096)

* The filesort sorting method applied to a CHAR(0) column could
lead to a server crash.
(Bug#49897: http://bugs.mysql.com/bug.php?id=49897)

* EXPLAIN EXTENDED UNION … ORDER BY caused a crash when the
ORDER BY referred to a nonconstant or full-text function or a
subquery. (Bug#49734: http://bugs.mysql.com/bug.php?id=49734)

* Some prepared statements could raise an assertion when
re-executed.
(Bug#49570: http://bugs.mysql.com/bug.php?id=49570)

* sql_buffer_result had an effect on non-SELECT statements,
contrary to the documentation.
(Bug#49552: http://bugs.mysql.com/bug.php?id=49552)

* In some cases a subquery need not be evaluated because it
returns only aggregate values that can be calculated from
table metadata. This sometimes was not handled by the
enclosing subquery, resulting in a server crash.
(Bug#49512: http://bugs.mysql.com/bug.php?id=49512)

* Mixing full-text searches and row expressions caused a crash.
(Bug#49445: http://bugs.mysql.com/bug.php?id=49445)

* Creating or dropping a table with 1023 transactions active
caused an assertion failure.
(Bug#49238: http://bugs.mysql.com/bug.php?id=49238)

* mysql-test-run.pl now recognizes the MTR_TESTCASE_TIMEOUT,
MTR_SUITE_TIMEOUT, MTR_SHUTDOWN_TIMEOUT, and MTR_START_TIMEOUT
environment variables. If they are set, their values are used
to set the –testcase-timeout, –suite-timeout,
–shutdown-timeout, and –start-timeout options, respectively.
(Bug#49210: http://bugs.mysql.com/bug.php?id=49210)

* Several strmake() calls had an incorrect length argument (too
large by one).
(Bug#48983: http://bugs.mysql.com/bug.php?id=48983)

* On Fedora 12, strmov() did not guarantee correct operation for
overlapping source and destination buffer. Calls were fixed to
use an overlap-safe version instead.
(Bug#48866: http://bugs.mysql.com/bug.php?id=48866)

* With one thread waiting for a lock on a table, if another
thread dropped the table and created a new table with the same
name and structure, the first thread would not notice that the
table had been re-created and would try to used cached
metadata that belonged to the old table but had been freed.
(Bug#48157: http://bugs.mysql.com/bug.php?id=48157)

* If an invocation of a stored procedure failed in the
table-open stage, subsequent invocations that did not fail in
that stage could cause a crash.
(Bug#47649: http://bugs.mysql.com/bug.php?id=47649)

* A crash occurred when a user variable that was assigned to a
subquery result was used as a result field in a SELECT
statement with aggregate functions.
(Bug#47371: http://bugs.mysql.com/bug.php?id=47371)

* When the mysql client was invoked with the –vertical option,
it ignored the –skip-column-names option.
(Bug#47147: http://bugs.mysql.com/bug.php?id=47147)

* If EXPLAIN encountered an error in the query, a memory leak
occurred. (Bug#45989: http://bugs.mysql.com/bug.php?id=45989)

* A race condition on the privilege hash tables allowed one
thread to try to delete elements that had already been deleted
by another thread. A consequence was that SET PASSWORD or
FLUSH PRIVILEGES could cause a crash.
(Bug#35589: http://bugs.mysql.com/bug.php?id=35589,
Bug#35591: http://bugs.mysql.com/bug.php?id=35591)

* 1) In rare cases, if a thread was interrupted during a FLUSH
PRIVILEGES operation, a debug assertion occurred later due to
improper diagnostic area setup. 2) A KILL operation could
cause a console error message referring to a diagnostic area
state without first ensuring that the state existed.
(Bug#33982: http://bugs.mysql.com/bug.php?id=33982)

* ALTER TABLE with both DROP COLUMN and ADD COLUMN clauses could
crash or lock up the server.
(Bug#31145: http://bugs.mysql.com/bug.php?id=31145)

* The Table_locks_waited waited variable was not incremented in
the cases that a lock had to be waited for but the waiting
thread was killed or the request was aborted.
(Bug#30331: http://bugs.mysql.com/bug.php?id=30331)

The “-m2″ suffix tells this belongs to the second milestone according to our “milestone” release model, also called “Betony”.
You can read more about the release model and the planned milestones at http://forge.mysql.com/wiki/Development_Cycle

The new features in this release are of beta quality. As with any other pre-production release, caution should be taken when installing on
production level systems or systems with critical data.

MySQL 5.5 is based on MySQL 5.4, which won’t get any further updates. So MySQL 5.5 includes several high-impact changes to address scalability
and performance issues in MySQL Server. These changes exploit advances in hardware and CPU design and enable better utilization of existing
hardware.

For an overview of what’s new in MySQL 5.5, please see the section “What Is New in MySQL 5.5″ below, or view it online at http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

For information on installing MySQL 5.5.1-m2 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.5/en/installing.html

For upgrading from previous MySQL releases, please see the important upgrade considerations at http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html

MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/

The list of all “Bugs Fixed” may also be viewed online at http://dev.mysql.com/doc/refman/5.5/en/news-5-5-1.html

When the publishing process for 5.5.1-m2 was already running, the MySQL team was informed about a security problem in the SSL connect area (a possibility to crash the server).

The problem is caused by a buffer overflow in the YaSSL library, MySQL Servers using OpenSSL are not affected. It can only occur when SSL (using YaSSL) is enabled.

This problem is still under detailed investigation with the various versions, configurations, and platforms.
When that has finished, the problem will be fixed ASAP, and new binaries for the affected versions will be released.

—–

What Is New in MySQL 5.5

The following features have been added to MySQL 5.5:

* Support for an interface for semisynchronous replication:
A commit performed on the master side blocks before returning
to the session that performed the transaction until at least
one slave acknowledges that it has received and logged the events
for the transaction.
Semisynchronous replication is implemented through an optional
plugin component. See Section 16.2.8, “Semisynchronous Replication”

* Support for the SQL standard SIGNAL and RESIGNAL statements.
See Section 12.8.8, “SIGNAL and RESIGNAL”.

* Enhancements to XML functionality, including a new LOAD XML
statement.

* Two new types of user-defined partitioning:
RANGE COLUMNS partitioning is an extension to RANGE partitioning;
LIST COLUMNS partitioning is an extension to LIST partitioning.
Each of these extensions provides two enhancements to MySQL
partitioning capabilities:

1. It is possible to define partitioning ranges or lists based on
DATE, DATETIME, or string values (such as CHAR or VARCHAR).

You can also define ranges or lists based on multiple column
values when partitioning tables by RANGE COLUMNS or LIST COLUMNS,
respectively. Such a range or list may refer to up to 16 columns.

2. For tables defined using these partitioning types, partition
pruning can now optimize queries with WHERE conditions that use
multiple comparisons between (different) column values and
constants, such as
a = 10 AND b > 5 or a < “2005-11-25″ AND b = 10 AND c = 50.

For more information, see Section 17.2.1, “RANGE Partitioning”,
and Section 17.2.2, “LIST Partitioning”.

* It is now possible to delete all rows from one or more partitions
of a partitioned table using the ALTER TABLE … TRUNCATE
PARTITION statement. Executing the statement deletes rows without
affecting the structure of the table. The partitions named in the
TRUNCATE PARTITION clause do not have to be contiguous.

* Key caches are now supported for indexes on partitioned MyISAM
tables, using the CACHE INDEX and LOAD INDEX INTO CACHE statements.
In addition, a key cache can be defined for and loaded with indexes
from an entire partitioned table, or for one or more partitions.
In the latter case, the partitions are not required to be contiguous.

* The TO_SECONDS() function is added. This function converts a date or
datetime expression to a number of seconds since the year 0. You may
use this function in partitioning expressions, and partition pruning
is supported for table defined using such expressions.

The following constructs are deprecated and will be removed in a future
MySQL release. Where alternatives are shown, applications should be
updated to use them.

* The table_type system variable (use storage_engine).

The TYPE table option to specify the storage engine for
CREATE TABLE or ALTER TABLE (use ENGINE).

The SHOW TABLE TYPES SQL statement (use SHOW ENGINES).

* The log_bin_trust_routine_creators variable
(use log_bin_trust_function_creators).

* TIMESTAMP(N): The ability to specify a display width of N
(use without N).

* The SHOW INNODB STATUS and SHOW MUTEX STATUS SQL statements
(use SHOW ENGINE INNODB STATUS for both of these).

* The LOAD TABLE … FROM MASTER and LOAD DATA FROM MASTER SQL
statements.

* The SHOW PLUGIN SQL statement (use SHOW PLUGINS).

* The BACKUP TABLE and the RESTORE TABLE SQL statements.

* The –master-xxx server options to set replication parameters
(use the CHANGE MASTER TO statement instead):
–master-host, –master-user, –master-password, –master-port,
–master-connect-retry, –master-ssl, –master-ssl-ca,
–master-ssl-capath, –master-ssl-cert, –master-ssl-cipher,
–master-ssl-key.

—–

Changes in MySQL 5.5.1-m2:

RPM Notes:

* The version information in RPM package files has been changed:
+ The “level” field of a MySQL version number is now also
included in the RPM version and in the package file name.
+ The RPM “release” value now starts to count from 1, not 0.
For example, the generic x86 server RPM file of 5.5.1-m2 is
named MySQL-server-5.5.1_m2-1.glibc23.i386.rpm. This improves
consistency with other formats that also include the level
(for this version: “m2″) in the file name. For example, the
tar.gz filename is mysql-5.5.1-m2-linux-i686-glibc23.tar.gz.
The different separator, underscore ‘_’ for RPM, is required
by the syntax of RPM.

InnoDB Plugin Notes:

* InnoDB Plugin has been upgraded to version 1.0.6. This version
is considered of Release Candidate (RC) quality. The InnoDB
Plugin Change History
(http://www.innodb.com/doc/innodb_plugin-1.0/innodb-changes.ht
ml) may contain information in addition to those changes
reported here.

Functionality added or changed:

* Partitioning: The UNIX_TIMESTAMP() function is now supported
in partitioning expressions using TIMESTAMP columns. For
example, it now possible to create a partitioned table such as
this one:
CREATE TABLE t (c TIMESTAMP)
PARTITION BY RANGE ( UNIX_TIMESTAMP(c) ) (
PARTITION p0 VALUES LESS THAN (631148400),
PARTITION p1 VALUES LESS THAN (946681200),
PARTITION p2 VALUES LESS THAN (MAXVALUE)
);
All other expressions involving TIMESTAMP values are now
rejected with an error when attempting to create a new
partitioned table or to alter an existing partitioned table.
When accessing an existing partitioned table having a
timezone-dependent partitioning function (where the table was
using a previous version of MySQL), a warning rather than an
error is issued. In such cases, you should fix the table. One
way of doing this is to alter the table’s partitioning
expression so that it uses UNIX_TIMESTAMP().
(Bug#42849: http://bugs.mysql.com/bug.php?id=42849)

Bugs fixed:

* Performance: 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.
(Bug#39253: http://bugs.mysql.com/bug.php?id=39253)
See also Bug#21074: http://bugs.mysql.com/bug.php?id=21074.

* Important Change: Replication: The following functions have
been marked unsafe for statement-based replication:
+ GET_LOCK()
+ IS_FREE_LOCK()
+ IS_USED_LOCK()
+ MASTER_POS_WAIT()
+ RELEASE_LOCK()
+ SLEEP()
+ SYSDATE()
+ VERSION()

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 format. When 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.
(Bug#47995: http://bugs.mysql.com/bug.php?id=47995)

* Partitioning: When SHOW CREATE TABLE was invoked for a table
that had been created using the COLUMNS keyword or the
TO_SECONDS() function, the output contained the wrong MySQL
version number in the conditional comments.
(Bug#49591: http://bugs.mysql.com/bug.php?id=49591)

* Partitioning: A query that searched on a ucs2 column failed if
the table was partitioned.
(Bug#48737: http://bugs.mysql.com/bug.php?id=48737)

* Partitioning: In some cases, it was not possible to add a new
column to a table that had subpartitions.
(Bug#48276: http://bugs.mysql.com/bug.php?id=48276)

* Partitioning: SELECT COUNT(*) from a partitioned table failed
when using the ONLY_FULL_GROUP_BY SQL mode.
(Bug#46923: http://bugs.mysql.com/bug.php?id=46923)
This regression was introduced by
Bug#45807: http://bugs.mysql.com/bug.php?id=45807.

* Partitioning: SUBPARTITION BY KEY failed with DEFAULT
CHARSET=utf8.
(Bug#45904: http://bugs.mysql.com/bug.php?id=45904)

* Replication: When using row-based logging, TRUNCATE TABLE was
written to the binary log even if the affected table was
temporary, causing replication to fail.
(Bug#48350: http://bugs.mysql.com/bug.php?id=48350)

* Cluster Replication: When expire_logs_days was set, the thread
performing the purge of the log files could deadlock, causing
all binary log operations to stop.
(Bug#49536: http://bugs.mysql.com/bug.php?id=49536)

* For debug builds on Windows, SAFEMALLOC was defined
inconsistently, leading to mismatches when using my_malloc()
and my_free().
(Bug#49811: http://bugs.mysql.com/bug.php?id=49811)

* The mysql.server script had incorrect shutdown logic.
(Bug#49772: http://bugs.mysql.com/bug.php?id=49772)

* The result of comparison between nullable BIGINT and INT
columns was inconsistent.
(Bug#49517: http://bugs.mysql.com/bug.php?id=49517)

* A Valgrind error in make_cond_for_table_from_pred() was
corrected. Thanks to Sergey Petrunya for the patch to fix this
bug. (Bug#49506: http://bugs.mysql.com/bug.php?id=49506)

* When compiling on Windows, an error in the CMake definitions
for InnoDB would cause the engine to be built incorrectly.
(Bug#49502: http://bugs.mysql.com/bug.php?id=49502)

* Incorrect cache initialization prevented storage of converted
constant values and could produce incorrect comparison
results. (Bug#49489: http://bugs.mysql.com/bug.php?id=49489)

* Comparisons involving YEAR values could produce incorrect
results. (Bug#49480: http://bugs.mysql.com/bug.php?id=49480)
See also Bug#43668: http://bugs.mysql.com/bug.php?id=43668.

* Valgrind warnings for CHECKSUM TABLE were corrected.
(Bug#49465: http://bugs.mysql.com/bug.php?id=49465)

* Specifying an index algorithm (such as BTREE) for SPATIAL or
FULLTEXT indexes caused a server crash. These index types do
not support algorithm specification, and it is now disallowed
to do so. (Bug#49250: http://bugs.mysql.com/bug.php?id=49250)

* The optimizer sometimes incorrectly handled conditions of the
form WHERE col_name=’const1′ AND col_name=’const2′.
(Bug#49199: http://bugs.mysql.com/bug.php?id=49199)

* Execution of DECODE() and ENCODE() could be inefficient
because multiple executions within a single statement
reinitialized the random generator multiple times even with
constant parameters.
(Bug#49141: http://bugs.mysql.com/bug.php?id=49141)

* The LIKE operator did not work correctly when using an index
for a ucs2 column.
(Bug#49028: http://bugs.mysql.com/bug.php?id=49028)

* check_key_in_view() was missing a DBUG_RETURN in one code
branch, causing a crash in debug builds.
(Bug#48995: http://bugs.mysql.com/bug.php?id=48995)

* If a query involving a table was terminated with KILL, a
subsequent SHOW CREATE TABLE for that table caused a server
crash. (Bug#48985: http://bugs.mysql.com/bug.php?id=48985)

* Privileges for stored routines were ignored for mixed-case
routine names.
(Bug#48872: http://bugs.mysql.com/bug.php?id=48872)
See also Bug#41049: http://bugs.mysql.com/bug.php?id=41049.

* Concurrent ALTER TABLE operations on an InnoDB table could
raise an assertion.
(Bug#48782: http://bugs.mysql.com/bug.php?id=48782)

* During query execution, ranges could be merged incorrectly for
OR operations and return an incorrect result.
(Bug#48665: http://bugs.mysql.com/bug.php?id=48665)

* The InnoDB Table Monitor reported the FLOAT and DOUBLE data
types incorrectly.
(Bug#48526: http://bugs.mysql.com/bug.php?id=48526)

* With row-based binary logging, the server crashed for
statements of the form CREATE TABLE IF NOT EXISTS
existing_view LIKE temporary_table. This occurred because the
server handled the existing view as a table when logging the
statement. (Bug#48506: http://bugs.mysql.com/bug.php?id=48506)

* The error message for ER_UPDATE_INFO was subject to buffer
overflow or truncation.
(Bug#48500: http://bugs.mysql.com/bug.php?id=48500)

* DISTINCT was ignored for queries with GROUP BY WITH ROLLUP and
only const tables.
(Bug#48475: http://bugs.mysql.com/bug.php?id=48475)

* Loose index scan was inappropriately chosen for some WHERE
conditions.
(Bug#48472: http://bugs.mysql.com/bug.php?id=48472)

* If the InnoDB tablespace was configured with too small a
value, the server could crash and corrupt the tablespace.
(Bug#48469: http://bugs.mysql.com/bug.php?id=48469)

* Parts of the range optimizer could be initialized incorrectly,
resulting in Valgrind errors.
(Bug#48459: http://bugs.mysql.com/bug.php?id=48459)

* A bad typecast could cause query execution to allocate large
amounts of memory.
(Bug#48458: http://bugs.mysql.com/bug.php?id=48458)

* On Windows, InnoDB could not be built as a statically linked
library. (Bug#48317: http://bugs.mysql.com/bug.php?id=48317)

* mysql_secure_installation did not work on Solaris.
(Bug#48086: http://bugs.mysql.com/bug.php?id=48086)

* When running mysql_secure_installation, the command would fail
if the root password contained multiple spaces, \, # or quote
characters.
(Bug#48031: http://bugs.mysql.com/bug.php?id=48031)

* MATCH IN BOOLEAN MODE searches could return too many results
inside a subquery.
(Bug#47930: http://bugs.mysql.com/bug.php?id=47930)

* User-defined collations with an ID less then 256 were not
initialized correctly when loaded and caused a server crash.
(Bug#47756: http://bugs.mysql.com/bug.php?id=47756)

* If a session held a global read lock acquired with FLUSH
TABLES WITH READ LOCK, a lock for one table acquired with LOCK
TABLES, and issued an INSERT DELAYED statement for another
table, deadlock could occur.
(Bug#47682: http://bugs.mysql.com/bug.php?id=47682)

* The mysql client status command displayed an incorrect value
for the server character set.
(Bug#47671: http://bugs.mysql.com/bug.php?id=47671)

* 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: http://bugs.mysql.com/bug.php?id=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: http://bugs.mysql.com/bug.php?id=47627)

* On Solaris, no stack trace was printed to the error log after
a crash. (Bug#47391: http://bugs.mysql.com/bug.php?id=47391)

* The innodb_file_format_check system variable could not be set
at runtime to DEFAULT or to the value of a user-defined
variable. (Bug#47167: http://bugs.mysql.com/bug.php?id=47167)

* After a binary upgrade to MySQL 5.1 from a MySQL 5.0
installation that contains ARCHIVE tables, accessing those
tables caused the server to crash, even if you had run
mysql_upgrade or CHECK TABLE … FOR UPGRADE.
To work around this problem, use mysqldump to dump all 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.
(Bug#47012: http://bugs.mysql.com/bug.php?id=47012)

* The IGNORE clause on a DELETE statement masked an SQL
statement error that occurred during trigger processing.
(Bug#46425: http://bugs.mysql.com/bug.php?id=46425)

* Valgrind errors for InnoDB Plugin were corrected.
(Bug#45992: http://bugs.mysql.com/bug.php?id=45992,
Bug#46656: http://bugs.mysql.com/bug.php?id=46656)

* The return value was not checked for some my_hash_insert()
calls. (Bug#45613: http://bugs.mysql.com/bug.php?id=45613)

* It was possible for init_available_charsets() not to
initialize correctly.
(Bug#45058: http://bugs.mysql.com/bug.php?id=45058)

* GROUP BY on a constant (single-row) InnoDB table joined to
other tables caused a server crash.
(Bug#44886: http://bugs.mysql.com/bug.php?id=44886)

* For YEAR(2) values, MIN(), MAX(), and comparisons could yield
incorrect results.
(Bug#43668: http://bugs.mysql.com/bug.php?id=43668)

* Comparison with NULL values sometimes did not produce a
correct result.
(Bug#42760: http://bugs.mysql.com/bug.php?id=42760)

* In debug builds, killing a LOAD XML INFILE statement raised an
assertion. (Bug#42520: http://bugs.mysql.com/bug.php?id=42520)

* The server could crash when attempting to access a
non-conformant 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.
(Bug#41726: http://bugs.mysql.com/bug.php?id=41726)

* The mysql_upgrade command would create three additional fields
to the mysql.proc table (character_set_client,
collation_connection, and db_collation), but did not populate
the fields with correct values. This would lead to error
messages reported during stored procedure execution.
(Bug#41569: http://bugs.mysql.com/bug.php?id=41569)

* Use of InnoDB monitoring (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.
(Bug#38883: http://bugs.mysql.com/bug.php?id=38883)

* When compressed MyISAM files were opened, they were always
memory mapped, sometimes causing memory-swapping problems. To
deal with this, a new system variable, myisam_mmap_size, was
added to limit the amount of memory used for memory mapping of
MyISAM files.
(Bug#37408: http://bugs.mysql.com/bug.php?id=37408)

* When running mysql_secure_installation on Windows, the command
would fail to load a required module, Term::ReadKey, which was
required for correct operation.
(Bug#35106: http://bugs.mysql.com/bug.php?id=35106)

* If the –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 .000001 and .index. The same thing occurred with the
–log-bin-index, –relay-log, and –relay-log-index options.
Now the server reports and error and exits.
(Bug#34739: http://bugs.mysql.com/bug.php?id=34739)

* 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: http://bugs.mysql.com/bug.php?id=34384)

* Using the SHOW ENGINE INNODB STATUS statement when using
partitions in InnoDB tables caused Invalid (old?) table or
database name errors to be logged.
(Bug#32430: http://bugs.mysql.com/bug.php?id=32430)

* Output from mysql –html did not encode the <, >, or &
characters.
(Bug#27884: http://bugs.mysql.com/bug.php?id=27884)

* Under heavy load with a large query cache, invalidating part
of the cache could cause the server to freeze (that is, to be
unable to service other operations until the invalidation was
complete). (Bug#21074: http://bugs.mysql.com/bug.php?id=21074)
See also Bug#39253: http://bugs.mysql.com/bug.php?id=39253.

* On some Windows systems, InnoDB could report Operating system
error number 995 in a file operation due to transient driver
or hardware problems. InnoDB now retries the operation and
adds Retry attempt is made to the error message.
(Bug#3139: http://bugs.mysql.com/bug.php?id=3139)