Changes in MySQL 5.5.5 (2010-07-06, Developer Milestone)

icc Notes

This is the final release of MySQL 5.5 for which Generic Linux
MySQL binary packages built with the icc
compiler on x86 and x86_64 will be offered. These were
previously produced as an alternative to our main packages built
using gcc, as they provided noticeable
performance benefits. In recent times the performance
differences have diminished and build and runtime problems have
surfaced, thus it is no longer viable to continue producing
them.

We continue to use the icc compiler to
produce our distribution-specific RPM packages on ia64.

InnoDB Notes

InnoDB has been upgraded to version 1.1.1.
This version is considered of “early adopter”
quality.

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

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

MyISAM remains the default storage engine
for the embedded version of MySQL.

Follow these steps to ensure a smooth transition when upgrading:

Familiarize yourself with the new default setting for the
InnoDB file-per-table option, which
creates a separate .ibd file for each
user table. Adapt any backup procedure to include these
files. For details, see
File-Per-Table Tablespaces.

Test the installation and operation for any applications
that you run on the database server, to determine if they
use any features specific to MyISAM that
cause problems during installation (when the tables are
created) or at runtime (when
MyISAM-specific features might fail, or
reliance on MyISAM settings for
performance might become apparent). The
InnoDB“strict” mode might
also alert you to problems while setting up tables for an
application.

As a preliminary test for individual tables rather than an
entire application, you can use the statement ALTER
TABLE table_name
ENGINE=INNODB; to convert an existing table to use
the InnoDB storage engine, and then run
compatibility and performance tests.

Where necessary, add ENGINE=MYISAM
clauses to CREATE TABLE
statements, for tables that require features specific to
MyISAM, such as full-text search.

Benchmark the most important queries, to check whether you
need to make changes to the table indexes.

Measure the performance of applications under typical load,
to check whether you need to change any additional
InnoDB configuration settings.

As a last resort, if a database server is devoted entirely
to applications that can only run with
MyISAM tables, you could add a
default-storage-engine line
in the configuration file, or a
--default-storage-engine
option in the database server startup command, to re-enable
MyISAM as the default storage engine for
that server. For details about setting the default storage
engine, see Setting the Storage Engine.

Platform-Specific Notes

Ubuntu 12.04 LTS: This is the last release
in the MySQL 5.5 series to support Ubuntu 12.04
LTS. As per the MySQL Support Lifecycle policy regarding ending
support for OS versions that are obsolete or have reached end of
life, we plan to discontinue building binaries for the Linux
distribution in future releases.
(Bug #25828475)

Functionality Added or Changed

Incompatible Change:
All numeric operators and functions on integer, floating-point
and DECIMAL values now throw an
“out of range” error
(ER_DATA_OUT_OF_RANGE) rather
than returning an incorrect value or NULL,
when the result is out of the supported range for the
corresponding data type. See
Out-of-Range and Overflow Handling.
(Bug #8433)

InnoDB:InnoDB stores redo log records in a
hash table during recovery. On 64-bit systems, this hash table
was 1/8 of the buffer pool size. To reduce memory usage, the
dimension of the hash table was reduced to 1/64 of the buffer
pool size (or 1/128 on 32-bit systems).
(Bug #53122)

Microsoft Windows:
Windows MSI package installers create and set up the data
directory that the installed server will use, but now also
create a pristine “template” data directory named
data under the installation directory. This
directory can be useful when the machine will be used to run
multiple instances of MySQL: After an installation has been
performed using an MSI package, the template data directory can
be copied to set up additional MySQL instances. See
Running Multiple MySQL Instances on One Machine.

Previously, the
innodb_file_format_check system
variable served a dual purpose. Setting it at server startup
would keep InnoDB from starting if any tables
used a more recent file format than supported by the current
level of InnoDB. If InnoDB
could start, the same system variable was set to the
“highest” file format value used by any
InnoDB table in the database. Thus, its value
could change from the value you specified.

Now, checking and recording the file format tag are handled
using separate variables.
innodb_file_format_check can be
set to 1 or 0 at server startup to enable or disable whether
InnoDB checks the file format tag in the
system tablespace. If the tag is checked and is higher than that
supported by the current version of InnoDB,
an error occurs and InnoDB does not start. If
the tag is not higher, InnoDB sets the value
of innodb_file_format_max to
the file format tag.

The Rows_examined value in slow query log
rows now is nonzero for UPDATE
and DELETE statements that modify
rows.
(Bug #49756)

For events of MYSQL_AUDIT_GENERAL_CLASS, the
event subclass was not passed to audit plugins even though the
server passed the subclass to the plugin handler. The subclass
is now available through the following changes:

The struct mysql_event_general structure
has a new event_subclass member.

The new member changes the interface, so the audit plugin
interface version,
MYSQL_AUDIT_INTERFACE_VERSION, has been
incremented from 0x0100 to
0x0200. Plugins that require access to
the new member must be recompiled to use version
0x0200 or higher.

The NULL_AUDIT example plugin in the
plugin/audit_null directory has been
modified to count events of each subclass, based on the
event_subclass value. See
Writing Audit Plugins.
(Bug #47059)

The deprecated mysql_fix_privilege_tables
script has been removed.
(Bug #42589)

A new system variable,
skip_name_resolve, is set from
the value of the
--skip-name-resolve server
option. This provides a way to determine at runtime whether the
server uses name resolution for client connections.
(Bug #37168)

Added the SHA2() function, which
calculates the SHA-2 family of hash functions (SHA-224, SHA-256,
SHA-384, and SHA-512). (Contributed by Bill Karwin)
(Bug #13174)

It is now possible to build MySQL on all platforms using
CMake instead of the GNU autotools. (Prior to
MySQL 5.5.5, CMake support was limited to
Windows.) For instructions on using CMake to
build MySQL, see Installing MySQL from Source.

Bugs Fixed

Security Fix:
The server could crash if there were alternate reads from two
indexes on a table using the
HANDLER interface.
(Bug #54007)

Security Fix:
A security bug was fixed.
(Bug #53933)

Security Fix:
A security bug was fixed.
(Bug #53907)

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 permitted 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)

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)

Security Fix:LOAD DATA
INFILE did not check for SQL errors and sent an OK
packet even when errors were already reported. Also, an assert
related to client/server protocol checking in debug servers
sometimes was raised when it should not have been.
(Bug #52512)

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)

Security Fix:
A security bug was fixed.
(Bug #48157)

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)

Incompatible Change:
After SET
TRANSACTION ISOLATION LEVEL to set the isolation level
for the next transaction, the session value of the
tx_isolation system variable
could appear to change to the transaction isolation level after
completion of statements within the transaction. Now the current
transaction isolation level is now established at transaction
start. If there was a
SET TRANSACTION
ISOLATION LEVEL statement, the value is taken from it.
Otherwise, the session
tx_isolation value is used. A
change in the session value while a transaction is active is
still permitted, but no longer affects the current transaction
isolation level. This is an incompatible change. A change in the
session isolation level made while there is no active
transaction overrides a
SET TRANSACTION
ISOLATION LEVEL statement, if there was any.
(Bug #20837)

Important Change; Replication:
It was possible to set
sql_log_bin with session scope
inside a transaction or subquery.
(Bug #53437)

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)

Important Change:
When using fast ALTER TABLE,
different internal ordering of indexes in the MySQL optimizer
and the InnoDB storage engine could
cause error messages about possibly mixed up
.frm files and incorrect index use.
(Bug #47622)

Performance; InnoDB:
Deadlock detection could be a bottleneck in
InnoDB processing, if many
transactions attempted to update the same row simultaneously.
The algorithm has been improved to enhance performance and
scalability, in the InnoDB Plugin for MySQL 5.1, and in InnoDB
1.1 for MySQL 5.5.
(Bug #49047)

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
are now preferred, making full table scans less likely.
(Bug #39653)

References: See also: Bug #55656.

InnoDB; Replication:TRUNCATE TABLE performed on a
temporary table using the InnoDB
storage engine was logged even when using row-based mode.
(Bug #51251)

InnoDB; Replication:
Reading from a table that used a self-logging storage engine and
updating a table that used a transactional engine (such as
InnoDB) generated changes that were written
to the binary log using statement format which could make slaves
diverge. However, when using mixed logging format, such changes
should be written to the binary log using row format. (This
issue did not occur when reading from tables using a
self-logging engine and updating MyISAM
tables, as this was already handled by checking for combinations
of nontransactional and transactional engines.) Now such
statements are classified as unsafe, and in mixed mode, cause a
switch to row-based logging.
(Bug #49019)

InnoDB:
The server could crash with a message InnoDB: Assertion
failure in thread nnnn,
typically during shutdown on a Windows system.
(Bug #53947)

InnoDB:
Some combinations of SELECT and
SELECT FOR UPDATE statements could fail with
errors about locks, or incorrectly release a row lock during a
semi-consistent
read operation.
(Bug #53674)

InnoDB:
Adding a unique key on multiple columns, where one of the
columns is NULL, could mistakenly report
duplicate key errors.
(Bug #53290)

InnoDB:
Fixed a checksum error reported for compressed tables when the
--innodb_checksums option is enabled.
Although the message stated that the table was corrupted, the
table is actually fine.
(Bug #53248)

InnoDB:
When reporting a foreign key constraint violation during
INSERT,
InnoDB could display uninitialized
data for the DB_TRX_ID and
DB_ROLL_PTR system columns.
(Bug #53202)

InnoDB:
The values of innodb_buffer_pool_pages_total
and innodb_buffer_pool_pages_misc in the
information_schema.global_status table could
be computed incorrectly.
(Bug #52983)

InnoDB:
An overly strict assertion could fail during the purge of
delete-marked records in DYNAMIC or
COMPRESSEDInnoDB tables that contain column
prefix indexes.
(Bug #52746)

InnoDB:InnoDB attempted to choose off-page
storage without ensuring that there was an “off-page
storage” flag in the record header. To correct this, in
DYNAMIC and COMPRESSED
formats, InnoDB stores locally any
non-BLOB columns having a maximum
length not exceeding 256 bytes. This is because there is no room
for the “external storage” flag when the maximum
length is 255 bytes or less. This restriction trivially holds in
REDUNDANT and COMPACT
formats, because there InnoDB
always stores locally columns having a length up to
local_len = 788 bytes.
(Bug #52745)

InnoDB:InnoDB checks to see whether a row could
possibly exceed the maximum size if all columns are fully used.
This produced Row size too large errors for
some tables that could be created with the built-in
InnoDB from older MySQL versions. Now the
check is only done when
innodb_strict_mode is enabled
or if the table is dynamic or compressed.
(Bug #50495)

InnoDB:
Multi-statement execution could fail with an error about foreign
key constraints. This problem could affect calls to
mysql_query() and
mysql_real_query(), and
CALL statements that invoke stored
procedures.
(Bug #48024)

InnoDB:
A mismatch between index information maintained within the
.frm files and the corresponding
information in the InnoDB system tablespace could produce this
error: [ERROR] Index index
of table has
n columns unique inside InnoDB, but
MySQL is asking statistics for m
columns. Have you mixed up .frm files from different
installations?
(Bug #44571)

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)

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)

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)

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)

Partitioning:
Attempting to partition a table using a
DECIMAL column caused the server
to crash; this was not supported and is now specifically not
permitted.
(Bug #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)

References: See also: Bug #47343, Bug #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)

Partitioning:
Foreign keys are not supported on partitioned tables. However,
it was possible using 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)

Partitioning:
It was possible to execute a CREATE TEMPORARY TABLE tmp
LIKE pt statement, where pt is a
partitioned table, even though partitioned temporary tables are
not permitted. This caused the server to crash. Now a check is
performed to prevent such statements from being executed.
(Bug #49477)

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)

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)

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)

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)

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)

References: This issue is a regression of: Bug #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)

Replication:
ACK packets in semisynchronous replication were not checked for
length and malformed packets could cause a server crash.
(Bug #52748)

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)

Replication:
A buffer overrun in the handling of
DATE column values could cause
mysqlbinlog to fail when reading logs
containing certain combinations of DML statements on a table
having a DATE column followed by
dropping the table.
(Bug #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)

Replication:
Issuing any DML on a temporary table temp
followed by DROP
TEMPORARY TABLE temp, both within the same
transaction, caused replication to fail.

The fix introduces a change to statement-based binary logging
with respect to temporary tables. Within a transaction, changes
to temporary tables are saved to the transaction cache and
written to the binary log when the transaction commits.
Otherwise, out-of-order logging of events could occur. This
means that temporary tables are treated similar to transactional
tables for purposes of caching and logging. This affects
assessment of statements as safe or unsafe and the associated
error message was changed from:

Unsafe statement written to the binary log using statement format
since BINLOG_FORMAT = STATEMENT. Statements that read from both
transactional and non-transactional tables and write to any of them
are unsafe.

To:

Unsafe statement written to the binary log using statement format
since BINLOG_FORMAT = STATEMENT. Statements that read from both
transactional (or a temporary table of any engine type) and
non-transactional tables and write to any of them are unsafe.

Replication:
The internal flag indicating whether a user value was signed or
unsigned (unsigned_flag) could sometimes
change between the time that the user value was recorded for
logging purposes and the time that the value was actually
written to the binary log, which could lead to inconsistency.
Now unsigned_flag is copied when the user
variable value is copied, and the copy of
unsigned_flag is then used for logging.
(Bug #51426, Bug #11759138)

References: See also: Bug #49562, Bug #11757508.

Replication:
Enabling
binlog_direct_non_transactional_updates
causes nontransactional changes to be written to the binary log
upon committing the statement. However, even when not enabled,
the addition of this variable introduced a number of undesired
changes in behavior:

When using ROW or
MIXED logging mode: Nontransactional
changes executed within a transaction prior to any
transactional changes were written to the statement cache,
but those following any transactional changes were written
to the transactional cache instead, causing these (later)
nontransactional changes to be lost.

When using ROW or
MIXED logging mode: When rolling back a
transaction, any nontransactional changes that might be in
the transaction cache were disregarded and truncated along
with the transactional changes.

When using STATEMENT logging mode: A
statement that combined transactional and nontransactional
changes prior to any other transactional changes within the
transaction, but failed, was kept in the transactional cache
until the transaction ended, rather than being written to
the binary log at the instant of failure (and not deferred
to the end of the transaction).

When using statement-based logging with
binlog_direct_non_transactional_updates
set to ON, any statement combining
transactional and nontransactional changes within the same
transaction is now stored in the transaction cache, whether
or not it succeeds, and regardless of its order of execution
among any transactional statements within that transaction.
This means that such a statement is now written to the
binary log only on transaction commit or rollback.

(Bug #51291)

References: This issue is a regression of: Bug #46364.

Replication:
When using temporary tables, the binary log needs to insert a
pseudo-thread ID for threads that are using temporary tables,
each time a switch happens between two threads, both of which
are using temporary tables. However, if a thread issued a
failing statement before exit, its ID was not recorded in the
binary log, and this in turn caused the ID for the next thread
that tried to do something with a temporary table not to be
logged as well. Subsequent replays of the binary log failed with
the error Table ... doesn't exist.
(Bug #51226)

References: This issue is a regression of: Bug #35583.

Replication:
If the master was using
sql_mode='TRADITIONAL',
duplicate key errors were not sent to the slave, which received
0 rather than the expected error code. This
caused replication to fail even when such an error was expected.
(Bug #51055)

Replication:
DDL statements that lock tables (such as
ALTER TABLE,
CREATE INDEX, and
CREATE TRIGGER) caused spurious
ER_BINLOG_ROW_MODE_AND_STMT_ENGINE or
ER_BINLOG_STMT_MODE_AND_ROW_ENGINE
errors, even though they did not insert rows into any tables.

Note

The error
ER_BINLOG_ROW_MODE_AND_STMT_ENGINE is
generated when
binlog_format=ROW and a
statement modifies a table restricted to statement-based
logging;
ER_BINLOG_STMT_MODE_AND_ROW_ENGINE is
generated when
binlog_format=STATEMENT and a
statement modifies a table restricted to row-based logging.

(Bug #50479)

References: This issue is a regression of: Bug #39934, Bug #11749859.

Replication:
When run with the --database
option, mysqlbinlog printed
ROLLBACK
statements but did not print any corresponding
SAVEPOINT statements.
(Bug #50407)

Replication:
When a CREATE EVENT statement was
followed by an additional statement and the statements were
executed together as a single statement, the
CREATE EVENT statement was padded
with “garbage” characters when written to the
binary log. This led to a syntax error when the event was read
from the log.
(Bug #50095)

Replication:
When using a nontransactional table on the master with
autocommit disabled, no COMMIT
was recorded in the binary log following a statement affecting
this table. If the slave's copy of the table used a
transactional storage engine, the result on the slave was as
though a transaction had been started, but never completed.
(Bug #49522)

References: See also: Bug #29288.

Microsoft Windows:
During MySQL server installation using the MSI package on
Windows, the default-character-set option
would be included in the default configuration template file.
This caused the MySQL server to fail to start properly.
(Bug #52380)

Microsoft Windows:
On Windows, LOAD_FILE() could
cause a crash for some pathnames.
(Bug #51893)

The make_binary_distribution target to
make could fail on some platforms because the
lines generated were too long for the shell.
(Bug #54590)

Inconsistent checking of the relationship between
SHOW statements and
INFORMATION_SCHEMA queries caused such
queries to fail sometimes.
(Bug #54422)

A crash occurred if a table that was locked with
LOCK TABLES was listed twice in a
DROP TABLE statement.
(Bug #54282)

ALTER TABLE for views is not
legal but did not produce an error. (If you need to rename a
view, use RENAME TABLE.)
(Bug #53976)

If the completion_type session
variable was changed after a stored procedure or prepared
statement had been cached, the change had no effect on
subsequent executions of the procedure or statement.
(Bug #53346)

The AND CHAIN option for
COMMIT and
ROLLBACK
failed to preserve the current transaction isolation level.
Setting completion_type to 1
also failed to do so.
(Bug #53343)

Incorrect results could be returned for LEFT
JOIN of InnoDB tables
with an impossible WHERE condition.
(Bug #53334)

The Lock_time value in the slow query log was
negative for stored routines.
(Bug #53191)

On some systems, such as OS X, the
sockaddr_in and
sockaddr_in6 structures contain a
non-standard field (sin_len /
sin6_len) that must be set but was not. This
resulted in host name lookup failure.
(Bug #52923)

In the debug version of the server, the
FreeState() function could in some
circumstances be called twice, leading to an assertion failure.
(Bug #52884)

With a non-latin1 ASCII-based current
character set, the server inappropriately converted
DATETIME values to strings. This
resulted in the optimizer not using indexes on such columns.
(Bug #52849)

mysqld_safe set
plugin_dir using a hardcoded
default path name rather than a path depending on
basedir.
(Bug #52737)

Semi-consistent read was implemented for
InnoDB to address Bug #3300.
Semi-consistent reads do not block when a nonmatching record is
already locked by some other transaction. If the record is not
locked, a lock is acquired, but is released if the record does
not match the WHERE condition. However,
semi-consistent read was attempted even for
UPDATE statements having a
WHERE condition of the form
pk_col1=constant1, ..., pk_colN=constantN.
Some code failed that was designed with the assumption that
semi-consistent read would be only attempted on table scans.
(Bug #52663)

References: See also: Bug #3300.

Setting
@@GLOBAL.debug
to an empty string failed to clear the current debug settings.
(Bug #52629)

SHOW CREATE TABLE was blocked if
the table was write locked by another session.
(Bug #52593)

The length and max_length
metadata values were incorrect for columns with the
TEXT family of data types that
used multibyte character sets. This bug was introduced in MySQL
5.5.3.
(Bug #52520)

mysql_upgrade attempted to work with stored
routines before they were available.
(Bug #52444)

The check_table_is_closed() debugging
function did not protect access to the
MyISAM open tables list, with the
result that server crashes could occur during table drop or
rename operations.
(Bug #52432)

Two sessions trying to set the global
event_scheduler system variable
to OFF resulted in one of them hanging
waiting for the event scheduler to stop.
(Bug #52367)

There was a race condition between flags used for signaling that
a query was killed, which led to error-reporting and
lock-acquisition problems.
(Bug #52356)

For a concurrent load of 16 or more connections containing many
LOCK TABLES
WRITE statements for the same table, server throughput
was significantly lower for MySQL 5.5.3 and 5.5.4 than for
earlier versions (10%–40% lower depending on concurrency).
(Bug #52289)

An assertion was raised as a result of a NULL
string being passed to the dtoa code.
(Bug #52165)

A memory leak occurred due to missing deallocation of the
comparators array (a member of the
Arg_comparator class).
(Bug #52124)

For debug builds, creating a view containing a subquery that
might require collation adjustment caused an assertion to be
raised. For example, this could occur if some items had
different collations but the result collation could be adjusted
to the one of them.
(Bug #52120)

ALTER TABLE on
InnoDB tables (including
partitioned tables) acquired exclusive locks on rows of the
table being altered. If there was a concurrent transaction that
did locking reads from this table, this sometimes led to a
deadlock that was not detected by the metadata lock subsystem or
by InnoDB (and was reported only after exceeding
innodb_lock_wait_timeout).
(Bug #51263)

A HAVING clause on a joined table in some
cases failed to eliminate rows which should have been excluded
from the result set.
(Bug #51242)

Two sessions trying to set the global
event_scheduler system variable
to different values could deadlock.
(Bug #51160)

InnoDB fast index creation could
incorrectly use a table copy in some cases.
(Bug #50946)

The Loose Index Scan optimization method assumed that it could
depend on the partitioning engine to maintain interval endpoint
information, as if it were a storage engine.
(Bug #50939)

The type inference used for view columns caused some columns in
views to be handled as the wrong type, as compared to the same
columns in base tables. DATE
columns in base tables were treated as
TIME columns in views, and base
table TIME columns as view
DATETIME columns.
(Bug #50918)

A syntactically invalid trigger could cause the server to crash
when trying to list triggers.
(Bug #50755)

Previously, the server held a global mutex while performing file
operations such as deleting an .frm or data
file, or reading index statistics from a data file. Now the
mutex is not held for these operations. Instead, the server uses
metadata locks.
(Bug #50589, Bug #51557, Bug #49463)

User-defined variables of type REAL that
contained NULL were handled improperly when
assigned to a column of another type.
(Bug #50511)

Performing a single in-place ALTER
TABLE containing ADD INDEX and
DROP INDEX options that used the same index
name could result in a corrupt table definition file. Now such
ALTER TABLE statements are no
longer performed in place.
(Bug #49838)

mysql_upgrade did not detect when
CSV log tables incorrectly
contained columns that could be NULL. Now
these columns are altered to be NOT NULL.
(Bug #49823)

In MySQL 5.1, READ COMMITTED
was changed to use less locking due to the availability of
row-based binary logging (see the Note under
READ COMMITTED at
SET TRANSACTION Syntax). However,
READ UNCOMMITTED did not have
the same change, so it was using more locks than the higher
isolation level, which is unexpected. This was changed so that
READ UNCOMMITTED now also
uses the lesser amount of locking and has the same restrictions
for binary logging.
(Bug #48607)

On Intel x86 machines, the optimizer could choose different
execution plans for a query depending on the compiler version
and optimization flags used to build the server binary.
(Bug #48537)

A trigger could change the behavior of assigning
NULL to a NOT NULL column.
(Bug #48525)

The server crashed when it could not determine the best
execution plan for queries involving outer joins with
nondeterministic ON clauses such as the ones
containing the RAND() function, a
user-defined function, or a NOT DETERMINISTIC
stored function.
(Bug #48483)

EXPLAIN could cause a server
crash for some queries with subqueries.
(Bug #48419)

The MERGE engine failed to open a
child table from a different database if the child table or
database name contained characters that were subject to table
name to file name encoding.

Further, the MERGE engine did not
properly open a child table from the same database if the child
table name contained characters such as '/',
or '#'.
(Bug #48265)

On Windows, the server failed to find a description for Event ID
100.
(Bug #48042)

A query that read from a derived table (of the form
SELECT ... FROM (SELECT ...)) produced
incorrect results when the following conditions were present:

The derived query could potentially produce zero rows or a
single NULL (that is, no rows matched, or
the query used an aggregate function such as
SUM() running over zero
rows).

The table subquery joined at least two tables.

The join condition involved an index.

(Bug #47904)

The optimization to read MIN() or
MAX() values from an index did
not properly handle comparisons with NULL
values. This could produce incorrect results for
MIN() or
MAX()when the
WHERE clause tested a NOT
NULL column for NULL.
(Bug #47762)

Killing a query during the optimization phase of a subquery
could cause a server crash.
(Bug #47761)

Using REPLACE to update a
previously inserted negative value in an
AUTO_INCREMENT column of an
InnoDB table caused the table
auto-increment value to be updated to 2147483647.
(Bug #47720)

In debug builds, if the listed columns in the view definition of
the table used in an
INSERT ...
SELECT statement mismatched, an assertion was raised
in the query cache invalidation code following the failing
statement.
(Bug #46615)

For the COMMIT and
ROLLBACK
statements, the AND CHAIN and
RELEASE modifiers should be mutually
exclusive, but the parser permitted both to be specified.
(Bug #46527)

The server could crash with an out of memory error when trying
to parse a query that was too long to fit in memory. Now the
parser rejects such queries with an
ER_OUT_OF_RESOURCES error.
(Bug #42064)

InnoDB could fail to create a unique index on
NULL columns.
(Bug #41904)

For a query that selected from a view and used an alias for the
view, the metadata used the alias name rather than the view name
in the MYSQL_FIELD.table member.
(Bug #41788)

mysql_upgrade did not create temporary files
properly.
(Bug #41057)

It was possible for DROP TABLE of
one MyISAM table to remove the data
and index files of a different
MyISAM table.
(Bug #40980)

If the arguments to a CONCAT()
call included a local routine variable, selecting the return
value into a user variable could produce an incorrect result.
(Bug #40625)

Column names displayed from the
PARTITION_EXPRESSION column of the
INFORMATION_SCHEMA.PARTITIONS table
did not include escape characters as necessary.
(Bug #39338)

When SET
TRANSACTION ISOLATION LEVEL was used to set the
isolation level for the next transaction, the level could
persist for subsequent transactions.
(Bug #39170)

When using UNINSTALL PLUGIN to
remove a loaded plugin, open tables and connections caused
mysqld to hang until the open connections had
been closed.
(Bug #39053)

Valgrind warnings in the InnoDBcompare_record() function were corrected.
(Bug #38999)

The optimizer sometimes used filesort for
ORDER BY when it should have used an index.
(Bug #38745)

Setting the session value of the
debug system variable also set
the global value.
(Bug #38054)

Accessing a MERGE table with an
empty underlying table list incorrectly resulted in a
“wrong index” error message rather than “end
of file.”
(Bug #35274)

The test for readline during configuration
failed when trying to build MySQL in a directory other than the
source tree root.
(Bug #35250)

mysqld could fail during execution when using
SSL.
(Bug #34236)

A query on a FEDERATED table in which the
data was ordered by a TEXT column returned
incorrect results. For example, a query such as the following
produced incorrect results if column column1
was a TEXT column:

The behavior of the RPM installation for both new installations
and upgrade installations has changed.

During a new installation, the server boot scripts are
installed, but the MySQL server is not started at the end of the
installation, since the status of the system during an
unattended installation is not known.

During an upgrade installation using the RPM packages, if the
server is running when the upgrade occurs, the server is
stopped, the upgrade occurs, and server is restarted. If the
server is not already running when the RPM upgrade occurs, the
server is not started at the end of the installation.

The boot scripts for MySQL are installed in the appropriate
directories in /etc, so the MySQL server
will be restarted automatically at the next machine reboot.
(Bug #27072)

ROW_COUNT() returned a meaningful value only
for some DML statements. Now it returns a value as follows:

SELECT: -1 if the statement
returns a result set, or the number of rows
“affected” if it does not. For example, for
SELECT * FROM t1,
ROW_COUNT() returns -1. For
SELECT * FROM t1 INTO OUTFILE
'file_name',
ROW_COUNT() returns the
number of rows written to the file.