MySQL 5.5 includes several high-impact enhancements to improve the performance and scalability of the MySQL Database, taking advantage of the latest multi-CPU and multi-core hardware and operating systems. In addition, with release 5.5, InnoDB is now the default storage engine for the MySQL Database, delivering ACID transactions, referential integrity and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

- Significantly improved performance on Windows, with various Windows specific features and improvements

- Higher availability, with new semi-synchronous replication and Replication Heart Beat

- Improved usability, with Improved index and table partitioning, SIGNAL/RESIGNAL support and enhanced diagnostics, including a new Performance Schema monitoring capability.

Changes in MySQL 5.5.14 :

Functionality added or changed:

* CMake configuration support on Linux now provides a boolean

ENABLE_GCOV option to control whether to include support for

gcov. (Bug #12549572)

* InnoDB now permits concurrent reads while creating a secondary

index. (Bug #11853126)

See also Bug #11751388, Bug #11784056, Bug #11815600.

* Client programs now display more information for SSL errors to

aid in diagnosis and debugging of connection problems. (Bug

#21287, Bug #11745920)

* In the audit plugin interface, the event_class member was

removed from the mysql_event_general structure and the calling

sequence for the notification function changed. Originally,

the second argument was a pointer to the event structure. The

function now receives this information as two arguments: an

event class number and a pointer to the event. Corresponding

to these changes, MYSQL_AUDIT_INTERFACE_VERSION was increased

to 0×0300.

The plugin_audit.h header file, and the NULL_AUDIT example

plugin in the plugin/audit_null directory have been modified

per these changes. See Section 21.2.4.7, “Writing Audit

Plugins.”

Bugs fixed:

* Replication: A mistake in thread cleanup could cause a

replication master to crash. (Bug #12578441)

* Replication: When using row-based replication and attribute

promotion or demotion (see Section 15.4.1.6.2, “Replication of

Columns Having Different Data Types”), memory allocated

internally for conversion of BLOB columns was not freed

afterwards. (Bug #12558519)

* Adding support for Windows authentication to libmysql

introduced a link dependency on the system Secur32 library.

The Microsoft Visual C++ link information was modified to pull

in this library automatically. (Bug #12612143)

* In some cases, memory allocated for

Query_tables_list::sroutines() was not freed properly. (Bug

#12429877)

* After the fix for Bug#11889186, MAKEDATE() arguments with a

year part greater than 9999 raised an assertion. (Bug

#12403504)

* An assertion could be raised due to a missing NULL value check

in Item_func_round::fix_length_and_dec(). (Bug #12392636)

* An assertion could be raised during two-phase commits if the

binary log was used as the transaction coordinator log. (Bug

#12346411)

* A problem introduced in 5.5.11 caused very old (MySQL 4.0)

clients to be unable to connect to the server. (Bug #61222,

Bug #12563279)

* Using CREATE EVENT IF NOT EXISTS for an event that already

existed and was enabled caused multiple instances of the event

to run. (Bug #61005, Bug #12546938)

* An embedded client would abort rather than issue an error

message if it issued a TEE command (\T file_name) and the

directory containing the file did not exist. This occurred

because the wrong error handler was called. (Bug #57491, Bug

#11764633)

* On some platforms, the Incorrect value: xxx for column yyy at

row zzz error produced by LOAD DATA INFILE could have an

incorrect value of zzz. (Bug #46895, Bug #11755168)

* An attempt to install nonexistent files during installation

was corrected. (Bug #43247, Bug #11752142)

* On FreeBSD 64-built builds of the embedded server, exceptions

were not prevented from propagating into the embedded

application. (Bug #38965, Bug #11749418)

MySQL 5.5 includes several high-impact enhancements to improve the

performance and scalability of the MySQL Database, taking advantage of

the latest multi-CPU and multi-core hardware and operating systems. In

addition, with release 5.5, InnoDB is now the default storage engine for

the MySQL Database, delivering ACID transactions, referential integrity

and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

- Significantly improved performance on Windows, with various Windows specific features and improvements

- Higher availability, with new semi-synchronous replication and Replication Heart Beat

- Improved usability, with Improved index and table partitioning, SIGNAL/RESIGNAL support and enhanced diagnostics, including a new Performance Schema monitoring capability.

————————————————————————

D.1.2. Changes in MySQL 5.5.11 (07 April 2011):

Functionality added or changed:

* The undocumented SHOW NEW MASTER statement has been removed.

Bugs fixed:

* Partitioning: A problem with a previous fix for poor

performance of INSERT ON DUPLICATE KEY UPDATE statements on

tables having many partitions caused the handler function for

reading a row from a specific index to fail to store the ID of

the partition last used. This caused some statements to fail

with Can’t find record errors. (Bug #59297, Bug #11766232)

* On some systems, debug builds of comp_err.c could fail due to

an uninitialized variable. (Bug #59906, Bug #11766729)

* The server read one byte too many when trying to process an

XML string lacking a closing quote (‘) or double quote (“)

character used as an argument for UpdateXML() or

ExtractValue(). (Bug #59901, Bug #11766725)

See also Bug #44332.

* Aggregation followed by a subquery could produce an incorrect

result. (Bug #59839, Bug #11766675)

* mysqldump did not quote database names in ALTER DATABASE

statements in its output, which could cause an error at reload

time for database names containing a dash. (Bug #59398, Bug

#11766310)

* If a multiple-table update updated a row through two aliases

and the first update physically moved the row, the second

update failed to locate the row. This resulted in different

errors depending on storage engine, although these errors did

not accurately describe the problem:

*

MyISAM: Got error 134 from storage engine

*

InnoDB: Can’t find record in ‘tbl’

For MyISAM, which is nontransactional, the update executed

first was performed but the second was not. In addition, for

two equal multiple-table update statements, one could succeed

and the other fail depending on whether the record actually

moved, which is inconsistent.||

Now such an update returns an error if it will update a table

through multiple aliases, and perform an update that may

physically more the row in at least one of these aliases. (Bug

#57373, Bug #11764529, Bug #55385, Bug #11762751)

* SHOW WARNINGS output following EXPLAIN EXTENDED could include

unprintable characters. (Bug #57341, Bug #11764503)

MySQL 5.5 includes several high-impact enhancements to improve the performance and scalability of the MySQL Database, taking advantage of the latest multi-CPU and multi-core hardware and operating systems. In addition, with release 5.5, InnoDB is now the default storage engine for the MySQL Database, delivering ACID transactions, referential integrity and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

- Significantly improved performance on Windows, with various Windows specific features and improvements

- Higher availability, with new semi-synchronous replication and Replication Heart Beat

- Improved usability, with Improved index and table partitioning, SIGNAL/RESIGNAL support and enhanced diagnostics, including a new PERFORMANCE_SCHEMA

The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.5.

—-

D.1.2. Changes in MySQL 5.5.10

Configuration Notes:

* MySQL releases are now built on all platforms using CMake

rather than the GNU autotools, so autotools support has been

removed. For instructions on building MySQL with CMake, see

Section 2.11, “Installing MySQL from Source.” Third-party

tools that need to extract the MySQL version number formerly

found in configure.in can use the VERSION file. See Section

2.11.6, “MySQL Configuration and Third-Party Tools.”

C API Notes:

* Incompatible Change: The shared library version of the client

library was increased to 18 to reflect ABI changes, and avoid

compatibility problems with the client library in MySQL 5.1.

Note that this is an incompatible change between 5.5.10 and

earlier 5.5 versions, so client programs that use the 5.5

client library should be recompiled against the 5.5.10 client

library.

Functionality added or changed:

* MySQL distributions now include auth_socket, a server-side

authentication plugin that authenticates clients that connect

from the local host through the Unix socket file. The plugin

uses the SO_PEERCRED socket option to obtain information about

the user running the client program (and thus can be built

only on systems that support this option. For a connection to

succeed, the plugin requires a match between the login name of

the connecting client user and the MySQL user name presented

by the client program. For more information, see Section

5.5.6.1.4, “The Socket Peer-Credential Authentication Plugin.”

(Bug #59017, Bug #11765993)

* The mysql_upgrade, mysqlbinlog, mysqlcheck, mysqlimport,

mysqlshow, and mysqlslap clients now have –default-auth and

–plugin-dir options for specifying which authentication

plugin and plugin directory to use. (Bug #58139)

* Boolean system variables can be enabled at run time by setting

them to the value ON or OFF, but previously this did not work

at server startup. Now at startup such variables can be

enabled by setting them to ON or TRUE, or disabled by setting

them to OFF or FALSE. Any other nonnumeric variable is

invalid. (Bug #46393)

See also Bug #51631.

* Previously, for queries that were aborted due to sort problem,

the server wrote the message Sort aborted to the error log.

Now the server writes more information to provide a more

specific message, such as:

[ERROR] mysqld: Sort aborted: Out of memory (Needed 24 bytes)

[ERROR] mysqld: Out of sort memory,

consider increasing server sort buffer size

[ERROR] mysqld: Sort aborted: Out of sort memory,

consider increasing server sort buffer size

[ERROR] mysqld: Sort aborted: Incorrect number of arguments for

FUNCTION test.f1; expected 0, got 1

In addition, if the server was started with –log-warnings=2,

the server write information about the host, user, and query.

(Bug #36022, Bug #11748358)

* mysqldump –xml now displays comments from column definitions.

(Bug #13618)

* MySQL distributions now include mysql_clear_password, a

client-side authentication plugin that sends the password to

the server without hashing or encryption. Although this is

insecure, and thus apprpropriate precautions should be taken

such as using an SSL connection, the plugin is useful in

conjunction with server-side plugins that must have access to

the original password in clear text. For more information, see

Section 5.5.6.1.3, “The Clear Text Client-Side Authentication

Plugin.”

Bugs fixed:

* InnoDB Storage Engine: Raised the number of I/O requests that

each AIO

(http://dev.mysql.com/doc/innodb/1.1/en/glossary.html#glos_aio

) helper thread could process, from 32 to 256. The new limit

applies to Linux and Unix platforms; the limit on Windows

remains 32. (Bug #59472)

* InnoDB Storage Engine: InnoDB returned values for “rows

examined” in the query plan that were higher than expected.

NULL values were treated in an inconsistent way. The

inaccurate statistics could trigger “false positives” in

combination with the MAX_JOIN_SIZE setting, because the

queries did not really examine as many rows as reported. (Bug

#30423)

* Replication: When using the statement-based logging format,

INSERT ON DUPLICATE KEY UPDATE and INSERT IGNORE statements

affecting transactional tables that did not fail were not

written to the binary log if they did not insert any rows.

(With statement-based logging, all successful statements

should be logged, whether they do or do not cause any rows to

be changed.) (Bug #59338)

* Replication: Formerly, STOP SLAVE stopped the slave I/O thread

first and then stopped the slave SQL thread; thus, it was

possible for the I/O thread to stop after replicating only

part of a transaction which the SQL thread was executing, in

which case—if the transaction could not be rolled back

safely—the SQL thread could hang.

Now, STOP SLAVE stops the slave SQL thread first and then

stops the I/O thread; this guarantees that the I/O thread can

fetch any remaining events in the transaction that the SQL

thread is executing, so that the SQL thread can finish the

transaction if it cannot be rolled back safely. (Bug #58546)

* DES_DECRYPT() could crash if the argument was not produced by

DES_ENCRYPT(). (Bug #59632, Bug #11766505)

* The server and client did not always properly negotiate

authentication plugin names. (Bug #59453)

* –autocommit=ON did not work (it set the global autocommit

value to 0, not 1). (Bug #59432)

* A query of the following form returned an incorrect result,

where the values for col_name in the result set were entirely

replaced with NULL values:

SELECT DISTINCT col_name … ORDER BY col_name DESC;

(Bug #59308, Bug #11766241)

* SHOW PRIVILEGES did not display a row for the PROXY privilege.

(Bug #59275)

* SHOW PROFILE could truncate source file names or fail to show

function names. (Bug #59273, Bug #11766214)

* DELETE or UPDATE statements could fail if they used DATE or

DATETIME values with a year, month, or day part of zero. (Bug

#59173)

* The ESCAPE clause for the LIKE operator allows only

expressions that evaluate to a constant at execution time, but

aggregate functions were not being rejected. (Bug #59149)

* Memory leaks detected by Valgrind, some of which could cause

incorrect query results, were corrected. (Bug #59110, Bug

#11766075)

* The DEFAULT_CHARSET and DEFAULT_COLLATION CMake options did

not work. (Bug #58991)

* An OUTER JOIN query using WHERE column IS NULL could return an

incorrect result. (Bug #58490, Bug #11765513)

* Starting the server with the –defaults-file=file_name option,

where the file name had no extension, caused a server crash.

(Bug #58455, Bug #11765482)

* Outer joins with an empty table could produce incorrect

results. (Bug #58422)

* In debug builds, SUBSTRING_INDEX(FORMAT(…), FORMAT(…))

could cause a server crash. (Bug #58371)

* When mysqladmin was run with the –sleep and –count options,

it went into an infinite loop executing the specified command.

(Bug #58221)

* Some string manipulating SQL functions use a shared string

object intended to contain an immutable empty string. This

object was used by the SQL function SUBSTRING_INDEX() to

return an empty string when one argument was of the wrong

datatype. If the string object was then modified by the SQL

function INSERT(), undefined behavior ensued. (Bug #58165, Bug

#11765225)

* Parsing nested regular expressions could lead to recursion

resulting in a stack overflow crash. (Bug #58026, Bug

#11765099)

* The fix for Bug#25192 caused load_defaults() to add an

argument separator to distinguish options loaded from

configure files from those provided on the command line,

whether or not the application needed it. (Bug #57953)

* The mysql client went into an infinite loop if the standard

input was a directory. (Bug #57450)

* Outer joins on a unique key could return incorrect results.

(Bug #57034)

* The expression const1 BETWEEN const2 AND field was optimized

incorrectly and produced incorrect results. (Bug #57030, Bug

#11764215)

* Some RPM installation scripts used a hardcoded value for the

data directory, which could result in a failed installation

for users who have a nonstandard data directory location. The

same was true for other configuration values such as the PID

file name. (Bug #56581, Bug #11763817)

* On FreeBSD and OpenBSD, the server incorrectly checked the

range of the system date, causing legal values to be rejected.

(Bug #55755, Bug #11763089)

* Sorting using ORDER BY AVG(DISTINCT decimal_col) caused a

server crash or incorrect results. (Bug #52123, Bug #11759784)

* When using ExtractValue() or UpdateXML(), if the XML to be

read contained an incomplete XML comment, MySQL read beyond

the end of the XML string when processing, leading to a crash

of the server. (Bug #44332)

* DATE_ADD() and DATE_SUB() return a string if the first

argument is a string, but incorrectly returned a binary

string. Now they return a character string with a collation of

connection_collation. (Bug #31384, Bug #11747221)

The first 5.5 production version of the world’s most popular open source database.  MySQL 5.5.8 is recommended for use on production systems.

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

hardware.  MySQL 5.5 also provides a number of other new enhancements, including:

- InnoDB I/O Subsystem Changes

- Enhanced Solaris Support

- Diagnostic and Monitoring Capabilities

The following section lists the changes in the MySQL source code since

the previous released version of MySQL 5.5.

—-

D.1.1. Changes in MySQL 5.5.8 (03 December 2010)

Configuration Notes:

* MySQL releases are now built on all platforms using CMake

rather than the GNU autotools, so autotools support has been

removed. For instructions on building MySQL with CMake, see

Section 2.11, “Installing MySQL from Source.” Third-party

tools that need to extract the MySQL version number formerly

found in configure.in can use the VERSION file. See Section

2.11.6, “MySQL Configuration and Third-Party Tools.”

Functionality added or changed:

* Support for the IBMDB2I storage engine has been removed.

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

* A –bind-address option has been added to a number of MySQL

client programs: mysql, mysqldump, mysqladmin, mysqlbinlog,

mysqlcheck, mysqlimport, and mysqlshow. This is for use on a

computer having multiple network interfaces, and enables you

to choose which interface is used to connect to the MySQL

server.

Bugs fixed:

* Performance: InnoDB Storage Engine: Improved concurrency when

several ANALYZE TABLE or SHOW TABLE STATUS statements are run

simultaneously for InnoDB tables.

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

* Incompatible Change: Previously, tables in the

performance_schema database had uppercase names. This was

incompatible with the lower_case_table_names system variable,

and caused issues when the variable value was changed after

installing or upgrading.

Now performance_schema table names are lowercase, so they

appear in uniform lettercase regardless of the

lower_case_table_names setting. References to these tables in

SQL statements should be given in lowercase. This is an

incompatible change, but provides compatible behavior across

different values of lower_case_table_names.

If you upgrade to MySQL 5.5.8 from an earlier version of MySQL

5.5, be sure to run mysql_upgrade (and restart the server) to

change the names of existing performance_schema tables from

uppercase to lowercase.

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

* Incompatible Change: The following changes were made to the

performance_schema.threads table for conformance with the

implementation in MySQL 5.6:

+ ID column: Renamed to PROCESSLIST_ID, removed NOT NULL

from definition.

+ NAME column: Changed from VARCHAR(64) to VARCHAR(128).

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

* Incompatible Change: Deadlock occurred when a connection that

had some table open through a HANDLER statement tried to

update data through a DML statement while another connection

tried to execute FLUSH TABLES WITH READ LOCK concurrently.

Starvation of FLUSH TABLES WITH READ LOCK statements occurred

when there was a constant load of concurrent DML statements in

two or more connections.

These problems resulted from the global read lock

implementation, which was reimplemented with the following

consequences:

+ To solve deadlock in event-handling code that was exposed

by this patch, the LOCK_event_metadata mutex was replaced

with metadata locks on events. As a result, DDL operations

on events are now prohibited under LOCK TABLES. This is

an incompatible change.

+ The global read lock (FLUSH TABLES WITH READ LOCK) no

longer blocks DML and DDL on temporary tables. Before

this patch, server behavior was not consistent in this

respect: In some cases, DML/DDL statements on temporary

tables were blocked; in others, they were not. Since the

main use cases for FLUSH TABLES WITH READ LOCK are

various forms of backups and temporary tables are not

preserved during backups, the server now consistently

allows DML/DDL on temporary tables under the global read

lock.

+ Thread state names are now either Waiting for global read

lock or Waiting for commit lock, depending on which stage

FLUSH TABLES WITH READ LOCK is in.

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

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

* InnoDB Storage Engine: Values could be truncated in certain

INFORMATION_SCHEMA columns, such as

REFERENTIAL_CONSTRAINTS.REFERENCED_TABLE_NAME and

KEY_COLUMN_USAGE.REFERENCED_TABLE_NAME.

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

* InnoDB Storage Engine: For an InnoDB table created with

ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, a query using the

READ UNCOMMITTED isolation level could cause the server to

stop with an assertion error, if BLOB or other large columns

that use off-page storage were being inserted at the same

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

* InnoDB Storage Engine: The server could stop with an assertion

error on Windows Vista and Windows 7 systems.

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

* InnoDB Storage Engine: A followup fix to

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

TABLE could still cause a crash (assertion error) in the

debug version of the server.

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

* InnoDB Storage Engine: The InnoDB system tablespace could grow

continually for a server under heavy load.

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

* InnoDB Storage Engine: Heavy concurrent updates of a BLOB

column in an InnoDB table could cause a hang.

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

* InnoDB Storage Engine: The innodb_stats_on_metadata option

could prevent the ANALYZE TABLE statement from running.

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

* InnoDB Storage Engine: A query for an InnoDB table could

return the wrong value if a column value was changed to a

different case, and the column had a case-insensitive index.

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

* InnoDB Storage Engine: An existing InnoDB could be switched to

ROW_FORMAT=COMPRESSED implicitly by a KEY_BLOCK_SIZE clause in

an ALTER TABLE statement. Now, the row format is only switched

to compressed if there is an explicit ROW_FORMAT=COMPRESSED

clause. on the ALTER TABLE statement.

Any valid, non-default ROW_FORMAT parameter takes precedence

over KEY_BLOCK_SIZE when both are specified. KEY_BLOCK_SIZE

only enables ROW_FORMAT=COMPRESSED if ROW_FORMAT is not

specified on either the CREATE TABLE or ALTER TABLE statement,

or is specified as DEFAULT. In case of a conflict between

KEY_BLOCK_SIZE and ROW_FORMAT clauses, the KEY_BLOCK_SIZE is

ignored if innodb_strict_mode is off, and the statement causes

an error if innodb_strict_mode is on.

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

* InnoDB Storage Engine: The clause KEY_BLOCK_SIZE=0 is now

allowed on CREATE TABLE and ALTER TABLE statements for InnoDB

tables, regardless of the setting of innodb_strict_mode. The

zero value has the effect of resetting the KEY_BLOCK_SIZE

table parameter to its default value, depending on the

ROW_FORMAT parameter, as if it had not been specified. That

default is 8 if ROW_FORMAT=COMPRESSED. Otherwise,

KEY_BLOCK_SIZE is not used or stored with the table

parameters.

As a consequence of this fix, ROW_FORMAT=FIXED is not allowed

when the innodb_strict_mode is enabled.

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

* InnoDB Storage Engine: A large number of foreign key

declarations could cause the output of the SHOW CREATE

STATEMENT statement to be truncated.

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

* InnoDB Storage Engine: A compilation problem affected the

InnoDB source code on NetBSD/sparc64.

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

* InnoDB Storage Engine: Clarified the message when a CREATE

TABLE statement fails because a foreign key constraint does

not have the required indexes.

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

* Partitioning: “Fast” ALTER TABLE operations (that do not

involve a table copy) on a partitioned table could leave the

table in an unusable state.

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

* Partitioning: An INSERT … ON DUPLICATE KEY UPDATE column = 0

statement on an AUTO_INCREMENT column caused the debug server

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

* Replication: Concurrent statements using a stored function and

a DROP DATABASE statement that caused the same stored function

to be dropped could cause statement-based replication to fail.

This problem is resolved by making sure that DROP DATABASE

takes an exclusive metadata lock on all stored functions and

stored procedures that it causes to be dropped.

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

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

* Replication: When STOP SLAVE is issued, the slave SQL thread

rolls back the current transaction and stops immediately if

the transaction updates only tables which use transactional

storage engines are updated. Previously, this occurred even

when the transaction contained CREATE TEMPORARY TABLE

statements, DROP TEMPORARY TABLE statements, or both, although

these statements cannot be rolled back. Because temporary

tables persist for the lifetime of a user session (in the

case, the replication user), they remain until the slave is

stopped or reset. When the transaction is restarted following

a subsequent START SLAVE statement, the SQL thread aborts with

an error that a temporary table to be created (or dropped)

already exists (or does not exist, in the latter case).

Following this fix, if an ongoing transaction contains CREATE

TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements,

or both, the SQL thread now waits until the transaction ends,

then stops.

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

* Replication: If there exist both a temporary table and a

non-temporary table having the same, updates normally apply

only to the temporary table, with the exception of a CREATE

TABLE … SELECT statement that creates a non-temporary table

having the same name as an existing temporary table. When such

a statement was replicated using the MIXED logging format, and

the statement was unsafe for row-based logging, updates were

misapplied to the temporary table.

Updates were also applied wrongly when a temporary table that

used a transactional storage engine was dropped inside a

transaction, followed by updates within the same transaction

to a non-temporary table having the same name.

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

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

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

* Replication: When making changes to relay log settings using

CHANGE MASTER TO, the I/O cache was not cleared. This could

result in replication failure when the slave attempted to read

stale data from the cache and then stopped with an assertion.

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

* Replication: Replication of SET and ENUM columns represented

using more than 1 byte (that is, SET columns with more than 8

members and ENUM columns with more than 256 constants) between

platforms using different endianness failed when using the

row-based format. This was because columns of these types are

represented internally using integers, but the internal

functions used by MySQL to handle them treated them as

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

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

* Replication: Trying to read from a binary log containing a log

event of an invalid type caused the slave to crash.

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

* Replication: When replicating the mysql.tables_priv table, the

Grantor column was not replicated, and was thus left empty on

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

* Setting the read_only system variable at server startup did

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

* mysql_upgrade failed after an upgrade from MySQL 5.1.

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

* When configuring the build with -DBUILD_CONFIG=mysql_release

and building with Visual Studio Express, the build failed if

signtool.exe was not present.

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

* When configuring the build with -DBUILD_CONFIG=mysql_release

on Linux, libaio is required, but the error message if it was

missing was uninformative.

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

* Use of NAME_CONST() in a HAVING clause caused a server crash.

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

* BETWEEN did not use indexes for DATE or DATETIME columns.

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

* Memory was allocated in fn_expand() for storing path names,

but not freed anywhere.

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

* In debug builds, inserting a FLOAT value into a CHAR(0) column

could crash the server.

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

* Failure to create a thread to handle a user connection could

result in a server crash.

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

* During configuration, ADD_VERSION_INFO in

cmake/mysql_version.cmake failed if LINK_FLAGS was modified.

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

* Performance Schema did not account for I/O for the binary log

file (no I/O was counted).

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

* Several compilation problems were fixed.

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

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

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

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

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

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

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

* After creating a table with two foreign key constraints, the

INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS table displayed

only one of them.

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

* Incorrect error handling raised an assertion if character set

conversion wrapped an item that failed.

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

* In debug builds, a missing DBUG_RETURN macro in sql/client.c

caused mysql to be unable to connect to the server.

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

* Clients using a client library older than MySQL 5.5.7 suffered

loss of connection after executing mysql_change_user() while

connected to a 5.5.7 server.

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

* The MySQL-shared RPM package failed to provide the lowercase

virtual identifier ‘mysql-shared’ in the RPM ‘Provides’ tags

(usually used for backward compatibility).

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

* For an upgrade to MySQL 5.5.7 from a previous release, the

server exited if the mysql.proxies_priv table did not exist,

making upgrades inconvenient. Now the server treats a missing

proxies_priv table as equivalent to an empty table. However,

after starting the server, you should still run mysql_upgrade

to create the table.

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

* SHOW PROCESSLIST displayed non-ASCII characters improperly.

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

* Passing a string that was not null-terminated to UpdateXML()

or ExtractValue() caused the server to fail with an assertion.

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

* SET GLOBAL debug could cause a crash on Solaris if the server

failed to open the trace file.

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

* In debug builds, an assertion could be raised during

conversion of strings to floating-point values.

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

* A user with no privileges on a stored routine or the

mysql.proc table could discover the routine’s existence.

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

* Queries executed using the Index Merge access method and a

temporary file could return incorrect results.

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

* The server could crash as a result of accessing freed memory

when populating INFORMATION_SCHEMA.VIEWS if a view could not

be opened properly.

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

* Valgrind warnings about overlapping memory when

double-assigning the same variable were corrected.

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

* If a STOP SLAVE statement was issued while the slave SQL

thread was executing a statement that invoked the SLEEP()

function, both statements hung.

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

* OPTIMIZE TABLE for InnoDB tables could raise an assertion.

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

* Warnings raised by a trigger were not cleared upon successful

completion. Now warnings are cleared if the trigger completes

successfully, per the SQL standard.

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

* For CMake builds, some parts of the source were unnecessarily

compiled twice if the embedded server was built.

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

* Boolean command options caused an error if given with an

option value and the loose- option prefix.

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

* An error in a stored procedure could leave the session in a

different default database.

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

* The CMake “wrapper” for configure (configure.pl) did not

handle the –with-comment option properly.

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

* Grouping by a TIME_TO_SEC() function result could cause a

server crash or incorrect results. Grouping by a function

returning a BLOB could cause an unexpected “Duplicate entry”

error and incorrect result.

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

* The find_files() function used by SHOW statements performed

redundant and unnecessary memory allocation.

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

* The Windows sample option files contained values more

appropriate for Linux.

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

* A failed RENAME TABLE operation could prevent a FLUSH TABLES

WITH READ LOCK from completing.

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

* Error messages for several internal conditions that should not

occur were changed to instruct the user to file a bug if they

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

* On file systems with case insensitive file names, and

lower_case_table_names=2, the server could crash due to a

table definition cache inconsistency.

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

* Handling of host name lettercase in GRANT statements was

inconsistent.

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

* SET NAMES utf8 COLLATE utf8_sinhala_ci did not work.

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

* The utf16_bin collation uses code-point order, not

byte-by-byte order, as described at Section 9.1.14.1, “Unicode

Character Sets.” (The order was byte-by-byte in MySQL 5.5.7.)

The “-rc” suffix indicates this is a “release candidate”. When there is sufficient positive feedback, there will be a “GA” (production quality) version of 5.5. From then on, MySQL 5.5 will receive production bug

fixing support.

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.

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

Changes in MySQL 5.5.7-rc:

Authentication Changes:

* MySQL authentication supports two new capabilities, pluggable

authentication and proxy users:

+ With pluggable authentication, the server can use plugins

to authenticate incoming client connections, and clients

can load an authentication plugin that interacts properly

with the corresponding server plugin. This capability

enables clients to connect to the MySQL server with

credentials that are appropriate for authentication

methods other than the built-in MySQL authentication

based on native MySQL passwords stored in the mysql.user

table. For example, plugins can be created to use

external authentication methods such as LDAP, Kerberos,

PAM, or Windows login IDs.

+ Proxy user capability enables a client who connects and

authenticates as one user to be treated, for purposes of

access control while connected, as having the privileges

of a different user. In effect, one user impersonates

another. Proxy capability depends on pluggable

authentication because it is based on having an

authentication plugin return to the server the user name

that the connecting user impersonates.

Pluggable authentication entails these changes:

+ For user specifications in the CREATE USER and GRANT

statements, a new IDENTIFIED WITH clause for specifying

the authentication plugin.

+ For the mysql.user table, new columns that specify plugin

information. The plugin column, if nonempty, indicates

which plugin authenticates connections for an account.

The authentication_string column is a string that is

passed to the plugin.

+ For the mysql_options() C API function, new

MYSQL_DEFAULT_AUTH and MYSQL_PLUGIN_DIR options that

enable client programs to load authentication plugins.

+ For the mysql client, new –default-auth and –plugin-dir

options for specifying which authentication plugin and

plugin directory to use.

+ For the mysqltest client, a new –plugin-dir option for

specifying which plugin directory to use, and a new

connect() command argument to specify an authentication

plugin.

+ For the server plugin API, a new

MYSQL_AUTHENTICATION_PLUGIN plugin type.

+ A client plugin API that enables client programs to

manage plugins.

+ Reimplementation of the built-in authentication methods

previously supported in MySQL as plugins. These methods

provide native password checking and pre-MySQL 4.1.1

authentication that uses shorter password hash values.

This change only reimplements the built-in methods as

plugins that cannot be unloaded. Existing clients

authenticate as before with no changes needed. In

particular, starting the server with the –secure-auth

option still prevents clients that have pre-4.1.1

password hashes from connecting, and –skip-grant-tables

still disables all password checking.

Proxy user capability entails these changes:

+ A new PROXY privilege that can be managed with the GRANT

and REVOKE statements.

+ New proxy_user and external_user system variables that

indicate whether the current session uses proxying.

+ A new mysql.proxies_priv grant table that records proxy

information for MySQL accounts.

Due to these changes, the server requires that the new grant

table, proxies_priv, be present in the mysql database. If you

are upgrading from a previous MySQL release rather than

performing a new installation, the server will exit during

startup after finding that this table is missing. To create

the table, start the server with the –skip-grant-tables

option to cause it to skip the normal grant table checks, then

run mysql_upgrade. For example:

shell> mysqld –skip-grant-tables &

shell> mysql_upgrade

Then stop the server and restart it normally.

You can specify other options on the mysqld command line if

necessary. Alternatively, if your installation is configured

so that the server normally reads options from an option file,

use the –defaults-file option to specify the file (enter each

command on a single line):

shell> mysqld –defaults-file=/usr/local/mysql/etc/my.cnf

–skip-grant-tables &

shell> mysql_upgrade

With the –skip-grant-tables option, the server does no

password or privilege checking, so any client can connect and

effectively have all privileges. For additional security, use

the –skip-networking option as well to prevent remote clients

from connecting.

For additional information, consult these references:

+ Information about pluggable authentication, including

installation and usage instructions: Section 5.5.6,

“Pluggable Authentication.”

+ Information about proxy users: Section 5.5.7, “Proxy

Users.”

+ Information about the server and client plugin API:

Section 23.2.4.1, “General Plugin Data Structures and

Functions.”

+ Information about the C API functions for managing client

plugins: See Section 22.9.10, “Client Plugin API C

Functions.”

Functionality added or changed:

* The unused and undocumented thread_pool_size system variable

was removed.

(Bug#57338)

* A new status variable, Handler_read_last, displays the number

of requests to read the last key in an index. With ORDER BY,

the server will issue a first-key request followed by several

next-key requests, whereas with With ORDER BY DESC, the server

will issue a last-key request followed by several previous-key

requests. (Bug#52312)

Bugs fixed:

* Performance: InnoDB Storage Engine: The master InnoDB

background thread could sometimes cause transient performance

drops due to excessive flushing of modified pages.

(Bug#56933)

* Security Fix: The server crashed for assignment of values of

types other than Geometry to items of type GeometryCollection

(MultiPoint, MultiCurve, MultiSurface). Now the server checks

the field type and fails with bad geometry value if it detects

incorrect parameters.

(Bug#55531)

* Security Fix: EXPLAIN EXTENDED caused a server crash with some

prepared statements.

(Bug#54494)

* Security Fix: In prepared-statement mode, EXPLAIN for a SELECT

from a derived table caused a server crash.

(Bug#54488)

* Security Fix: The PolyFromWKB() function could crash the

server when improper WKB data was passed to the function.

(Bug#51875,

CVE-2010-3840

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

* Incompatible Change: Replication: The behavior of INSERT

DELAYED statements when using statement-based replication has

changed as follows:

Previously, when using binlog_format=STATEMENT, a warning was

issued in the client when executing INSERT DELAYED; now, no

warning is issued in such cases.

Previously, when using binlog_format=STATEMENT, INSERT DELAYED

was logged as INSERT DELAYED; now, it is logged as an INSERT,

without the DELAYED option.

However, when binlog_format=STATEMENT, INSERT DELAYED

continues to be executed as INSERT (without the DELAYED

option). The behavior of INSERT DELAYED remains unchanged when

using binlog_format=ROW: INSERT DELAYED generates no warnings,

is executed as INSERT DELAYED, and is logged using the

row-based format.

This change also affects binlog_format=MIXED, because INSERT

DELAYED is no longer considered unsafe. Now, when the logging

format is MIXED, no switch to row-based logging occurs. This

means that the statement is logged as a simple INSERT (that

is, without the DELAYED option), using the statement-based

logging format.

(Bug#54579)

* Incompatible Change: Previously, if you flushed the logs using

FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the

error log to a file (for example, if it was started with the

–log-error option), it renamed the current log file with the

suffix -old, then created a new empty log file. This had the

problem that a second log-flushing operation thus caused the

original error log file to be lost unless you saved it under a

different name. For example, you could use the following

commands to save the file:

shell> mysqladmin flush-logs

shell> mv host_name.err-old backup-directory

To avoid the preceding file-loss problem, renaming no longer

occurs. The server merely closes and reopens the log file. To

rename the file, you can do so manually before flushing. Then

flushing the logs reopens a new file with the original file

name. For example, you can rename the file and create a new

one using the following commands:

shell> mv host_name.err host_name.err-old

shell> mysqladmin flush-logs

shell> mv host_name.err-old backup-directory

(Bug#29751)

* InnoDB Storage Engine: Replication: If the master had

innodb_file_per_table=OFF, innodb_file_format=Antelope (and

innodb_strict_mode=OFF), or both, certain CREATE TABLE

options, such as KEY_BLOCK_SIZE, were ignored. This could

allow master to avoid raising ER_TOO_BIG_ROWSIZE errors.

However, the ignored CREATE TABLE options were still written

into the binary log, so that, if the slave had

innodb_file_per_table=ON and innodb_file_format=Barracuda, it

could encounter an ER_TOO_BIG_ROWSIZE error while executing

the record from the log, causing the slave SQL thread to abort

and replication to fail.

In the case where the master was running MySQL 5.1 and the

slave was MySQL 5.5 (or later), the failure occurred when both

master and slave were running with default values for

innodb_file_per_table and innodb_file_format. This could cause

problems during upgrades.

To address this issue, the default values for

innodb_file_per_table and innodb_file_format are reverted to

the MySQL 5.1 default values—that is, OFF and Antelope,

respectively.

(Bug#56318)

* InnoDB Storage Engine: The server could crash with a high

volume of concurrent LOCK TABLE and UNLOCK TABLES statements.

(Bug#57345)

* InnoDB Storage Engine: InnoDB incorrectly reported an error

when a cascading foreign key constraint deleted more than 250

rows. (Bug#57255)

* InnoDB Storage Engine: The output from the SHOW ENGINE INNODB

STATUS command can now be up to 1 MB. Formerly, it was

truncated at 64 KB. Monitoring applications that parse can

check if output exceeds this new, larger limit by testing the

Innodb_truncated_status_writes status variable.

(Bug#56922)

* InnoDB Storage Engine: A SELECT … FOR UPDATE statement

affecting a range of rows in an InnoDB table could cause a

crash in the debug version of the server.

(Bug#56716)

* InnoDB Storage Engine: Improved the performance of UPDATE

operations on InnoDB tables, when only non-indexed columns are

changed. (Bug#56340)

* InnoDB Storage Engine: When MySQL was restarted after a crash

with the option innodb_force_recovery=6, certain queries

against InnoDB tables could fail, depending on WHERE or ORDER

BY clauses.

Usually in such a disaster recovery situation, you dump the

entire table using a query without these clauses. During

advanced troubleshooting, you might use queries with these

clauses to diagnose the position of the corrupted data, or to

recover data following the corrupted part.

(Bug#55832)

* InnoDB Storage Engine: The CHECK TABLE command could cause a

time-consuming verification of the InnoDB adaptive hash index

memory structure. Now this extra checking is only performed in

binaries built for debugging.

(Bug#55716)

* InnoDB Storage Engine: A heavy workload with a large number of

threads could cause a crash in the debug version of the

server. (Bug#55699)

* InnoDB Storage Engine: The server could crash on shutdown, if

started with –innodb-use-system-malloc=0.

(Bug#55627)

* InnoDB Storage Engine: If the server crashed during a RENAME

TABLE operation on an InnoDB table, subsequent crash recovery

could fail. This problem could also affect an ALTER TABLE

statement that caused a rename operation internally.

(Bug#55027)

* InnoDB Storage Engine: Setting the PACK_KEYS=0 table option

for an InnoDB table prevented new indexes from being added to

the table. (Bug#54606)

* InnoDB Storage Engine: Changed the locking mechanism for the

InnoDB data dictionary during ROLLBACK operations, to improve

concurrency for REPLACE statements.

(Bug#54538)

* InnoDB Storage Engine: With multiple buffer pools enabled,

InnoDB could flush more data from the buffer pool than

necessary, causing extra I/O overhead.

(Bug#54346)

* InnoDB Storage Engine: InnoDB transactions could be

incorrectly committed during recovery, rather than rolled

back, if the server crashed and was restarted after performing

ALTER TABLE…ADD PRIMARY KEY on an InnoDB table, or some

other operation that involves copying the entire table.

(Bug#53756)

* InnoDB Storage Engine: InnoDB startup messages now include the

start and end times for buffer pool initialization, and the

total buffer pool size.

(Bug#48026)

* Partitioning: Multi-table UPDATE statements involving a

partitioned MyISAM table could cause this table to become

corrupted. Not all tables affected by the UPDATE needed to be

partitioned for this issue to be observed.

(Bug#55458)

* Partitioning: EXPLAIN PARTITIONS returned bad estimates for

range queries on partitioned MyISAM tables. In addition,

values in the rows column of EXPLAIN PARTITIONS output did not

take partition pruning into account.

(Bug#53806,

Bug#46754)

* Replication: SET PASSWORD caused row-based replication to fail

between a MySQL 5.1 master and a MySQL 5.5 slave.

This fix makes it possible to replicate SET PASSWORD

correctly, using row-based replication between a master

running MySQL 5.1.53 or a later MySQL 5.1 release to a slave

running MySQL 5.5.7 or a later MySQL 5.5 release.

(Bug#57098)

See also Bug#55452,

Bug#57357.

* Replication: Backticks used to enclose identifiers for

savepoints were not preserved in the binary log, which could

lead to replication failure when the identifier, stripped of

backticks, could be misinterpreted, causing a syntax or other

error.

This could cause problems with MySQL application programs

making use of generated savepoint IDs. If, for instance,

java.sql.Connection.setSavepoint() is called without any

parameters, Connector/J automatically generates a savepoint

identifier consisting of a string of hexadecimal digits 0-F

encased in backtick (`) characters. If such an ID took the

form `NeN` (where N represents a string of the decimal digits

0-9, and e is a literal uppercase or lowercase “E” character).

Removing the backticks when writing the identifier into the

binary log left behind a substring which the slave MySQL

server tried to interpret as a floating point number, rather

than as an identifier. The resulting syntax error caused loss

of replication.

(Bug#55961)

See also Bug#55962.

* Replication: When a slave tried to execute a transaction

larger than the slave’s value for max_binlog_cache_size, it

crashed. This was caused by an assertion that the server

should roll back only the statement but not the entire

transaction when the error ER_TRANS_CACHE_FULL occurred.

However, the slave SQL thread always rolled back the entire

transaction whenever any error occurred, regardless of the

type of error.

(Bug#55375)

* Replication: The error message for

ER_SLAVE_HEARTBEAT_VALUE_OUT_OF_RANGE was hard coded in

English in sql_yacc.yy, so that it could not be translated in

errmsg.txt for other languages.

Additionally, this same error message was used for three

separate error conditions:

1. When the heartbeat period exceeded the value of

slave_net_timeout.

2. When the heartbeat period was nonnegative but shorter

than 1 millisecond.

3. When the value for the heartbeat period was either

negative or greater than the maximum allowed.

These issues have been addressed as follows:

+ By using three distinct error messages for each of the

conditions listed previously.

+ By moving the sources for these error messages into the

errmsg-utf8.txt file to facilitate translations into

languages other than English.

(Bug#54144)

* A buffer overrun could occur when formatting DBL_MAX numbers.

(Bug#57209)

* The server could crash inside memcpy() when reading certain

Performance Schema tables.

(Bug#56761)

* Memory leaks detected by Valgrind were corrected.

(Bug#56709)

* It was possible to compile mysqld with Performance Schema

support but with a dummy atomic-operations implementation,

which caused a server crash. This problem does not affect

binary distributions. It is helpful as a safety measure for

users who build MySQL from source.

(Bug#56521)

* The server crashed if a table maintenance statement such as

ANALYZE TABLE or REPAIR TABLE was executed on a MERGE table

and opening and locking a child table failed. For example,

this could happen if a child table did not exist or if a lock

timeout happened while waiting for a conflicting metadata lock

to disappear.

As a consequence of this bug fix, it is now possible to use

CHECK TABLE for log tables without producing an error.

(Bug#56422,

Bug#56494)

* Deadlock could occur for heavily concurrent workloads

consisting of a mix of DML, DDL, and FLUSH TABLES statements

affecting the same set of tables.

(Bug#56405)

* The server could crash during shutdown due to a race condition

relating to Performance Schema cleanup.

(Bug#56324)

* ALTER TABLE on a MERGE table could result in deadlock with

other connections.

(Bug#56292,

Bug#57002)

* The tcmalloc library was missing from binary MySQL packages

for Linux. (Bug#56267)

* An INSERT DELAYED statement for a MERGE table could cause

deadlock if it occurred as part of a transaction or under LOCK

TABLES, and there was a concurrent DDL or LOCK TABLES …

WRITE statement that tried to lock one of its underlying

tables. (Bug#56251)

* In debug builds, the server raised an assertion for DROP

DATABASE in installations that had an outdated or corrupted

mysql.proc table. For example, this affected mysql_upgrade

when run as part of a MySQL 5.1 to 5.5 upgrade.

(Bug#56137)

* A negative TIME argument to MIN() or MAX() could raise an

assertion. (Bug#56120)

* The ordering for supplementary characters with the

utf8mb4_bin, utf16_bin, and utf32_bin collations was

incorrect. (Bug#55980)

* Short (single-letter) command-line options did not work.

(Bug#55873)

* If a query specified a DATE or DATETIME value in a format

different from ‘YYYY-MM-DD HH:MM:SS’, a greater-than-or-equal

(>=) condition matched only greater-than values in an indexed

TIMESTAMP column.

(Bug#55779)

* If a view was named as the destination table for CREATE TABLE

… SELECT, the server produced a warning whether or not IF

NOT EXISTS was used. Now it produces a warning only when IF

NOT EXISTS is used, and an error otherwise.

(Bug#55777)

* After the fix for

Bug#39653, the

shortest available secondary index was used for full table

scans. The primary clustered key was used only if no secondary

index could be used. However, when the chosen secondary index

includes all columns of the table being scanned, it is better

to use the primary index because the amount of data to scan is

the same but the primary index is clustered. This is now taken

into account.

(Bug#55656)

* For Performance Schema, the default number of rwlock classes

was increased to 30, and the default number of rwlock and

mutex instances was increased to 1 million. These changes were

made to account for the volume of data instrumented when the

InnoDB storage engine is used (because of the InnoDB buffer

pool). (Bug#55576)

* If there was an active SELECT statement, an error arising

during trigger execution could cause a server crash.

(Bug#55421)

* Assignment of InnoDB scalar subquery results to a variable

resulted in unexpected S locks in READ COMMITTED transaction

isolation level.

(Bug#55382)

* Queries involving predicates of the form const NOT BETWEEN

not_indexed_column AND indexed_column could return incorrect

data due to incorrect handling by the range optimizer.

(Bug#54802)

* With an UPDATE IGNORE statement including a subquery that was

evaluated using a temporary table, an error transferring the

data from the temporary was ignored, causing an assertion to

be raised. (Bug#54543)

* MIN() or MAX() with a subquery argument could raise a debug

assertion for debug builds or return incorrect data for

nondebug builds.

(Bug#54465)

* If one session attempted to drop a database containing a table

which another session had opened with HANDLER, any instance of

ALTER DATABASE, CREATE DATABASE, or DROP DATABASE issued by

the latter session produced a deadlock.

(Bug#54360)

* INFORMATION_SCHEMA plugins with no deinit() method resulted in

a memory leak.

(Bug#54253)

* Row subqueries producing no rows were not handled as UNKNOWN

values in row comparison expressions.

(Bug#54190)

* Setting SETUP_INSTRUMENTS.TIMER = ‘NO’ caused TIMER_WAIT

values for aggregations to be NULL rather than 0.

(Bug#53874)

* The max_length metadata value of MEDIUMBLOB types was reported

as 1 byte greater than the correct value.

(Bug#53296)

* If an application using the embedded server called

mysql_library_init() a second time after calling

mysql_library_init() and mysql_library_end() to start and stop

the server, the application crashed when reading option files.

(Bug#53251)

* The fix for Bug#30234

caused the server to reject the DELETE tbl_name.* … Access

compatibility syntax for multiple-table DELETE statements.

(Bug#53034)

* The plugin_ftparser.h and plugin_audit.h include files are

part of the public API/ABI, but were not tested by the ABI

check. (Bug#52821)

* An atomic “compare and swap” operation using x86 assembly code

(32 bit) could access incorrect data, which would make it work

incorrectly and lose the intended atomicity. This would in

turn cause the MySQL server to work on inconsistent data

structures and return incorrect data. That code part affected

only 32-bit builds; the effect has been observed when icc was

used to build binaries. With gcc, no incorrect results have

been observed during tests, so this fix is a proactive one.

Other compilers do not use this assembly code.

(Bug#52419)

* In LOAD DATA INFILE, using a SET clause to set a column equal

to itself caused a server crash.

(Bug#51850)

* In some cases, when the left part of a NOT IN subquery

predicate was a row and contained NULL values, the query

result was incorrect.

(Bug#51070)

* CHECKSUM TABLE for Performance Schema tables could cause a

server crash due to uninitialized memory reads.

(Bug#50557)

* For some queries, the optimizer produced incorrect results

using the Index Merge access method with InnoDB tables.

(Bug#50402)

* EXPLAIN produced an incorrect rows value for queries evaluated

using an index scan and that included LIMIT, GROUP BY, and

ORDER BY on a computed column.

(Bug#50394)

* mysql_store_result() and mysql_use_result() are not for use

with prepared statements and are not intended to be called

following mysql_stmt_execute(), but failed to return an error

when invoked that way.

(Bug#47485)

* Using REPAIR TABLE table USE_FRM on a MERGE table caused the

server to crash.

(Bug#46339)

* If the global and session debug system variables had the same

value, the debug trace file could be closed twice, leading to

freeing already freed memory and a server crash.

(Bug#46165)

* Trailing space removal for utf32 strings was done with

non-multibyte-safe code, leading to incorrect result length

and assertion failure.

(Bug#42511)

* A malformed packet sent by the server when the query cache was

in use resulted in lost-connection errors.

(Bug#42503)

* Multiple-statement execution could fail.

(Bug#40877)

* CREATE TABLE failed if a column referred to in an index

definition and foreign key definition was in different

lettercases in the two definitions.

(Bug#39932)

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)