InnoDB Plugin Notes:
In this release, the
InnoDB Plugin is
included in source and binary distributions, except RHEL3,
RHEL4, SuSE 9 (x86, x86_64, ia64), and generic Linux RPM
packages. It also does not work for FreeBSD 6 and HP-UX or for
Linux on S/390, PowerPC, and generic ia64.
In binary installations of MySQL, the supplied
binary-configure script would start and
configure MySQL, even when command help was requested with the
--help command-line option. The
--help, if provided, will no longer start and
install the server.
Partitioning: When reorganizing partitions, not all affected subpartitions were removed prior to renaming. One way in which the issue was visible was that attempting to reorganize two partitions into a single partition having the same name as one of the original partitions could lead to a crash of the server. (Bug#47029)
An online or fast
ALTER TABLE of
a partitioned table could leave behind temporary files in the
This issue was observed in MySQL 5.1.31 and later only. (Bug#46483)
When performing an
SELECT into a partitioned table,
read_buffer_size bytes of
memory were allocated for every partition in the target table,
resulting in consumption of large amounts of memory when the
table had many partitions (more than 100).
Inserting negative values into an
AUTO_INCREMENT column of a partitioned table
could lead to apparently unrelated errors or a crash of the
Partitioning: Unnecessary calls were made in the server code for performing bulk inserts on partitions for which no inserts needed to be made. (Bug#35845)
See also Bug#35843.
When using row-based replication,
DROP TEMPORARY TABLE
IF EXISTS was written to the binary log if the table
named in the statement did not exist, even though a
TABLE statement should never be logged in row-based
logging mode, whether the table exists or not.
When using row-based replication, importing a dump made with
mysqldump and replicating a row with an
AUTO_INCREMENT column set to 0, with
on the master, the row was inserted successfully on the master;
however any setting for
ignored on the slave. When the
column was incremented, this caused replication to fail on the
slave due to a duplicate key error. In some cases it could also
cause the slave to crash.
Concurrent transactions that inserted rows into a table with an
AUTO_INCREMENT column could break
statement-based or mixed-format replication error 1062
Duplicate entry '...' for key 'PRIMARY'
on the slave. This was especially likely to happen when one of
the transactions activated a trigger that inserted rows into the
table with the
although other conditions could also cause the issue to
Replication: By default, all statements executed by the mysql_upgrade program on the master are written to the binary log, then replicated to the slave. In some cases, this can result in problems; for example, it attempted to alter log tables on replicated databases (this failed due to logging being enabled).
On the master, if a binary log event is larger than
max_allowed_packet, the error
sent to a slave when it requests a dump from the master, thus
leading the I/O thread to stop. On a slave, the I/O thread stops
when receiving a packet larger than
In both cases, however, there was no
reported, which made it difficult to determine why the slave had
stopped in such cases. Now,
is reported when
max_allowed_packet is exceeded,
and provides the reason for which the slave I/O thread stopped.
API: The fix for Bug#24507 could lead in some cases to client application failures due to a race condition. Now the server waits for the “dummy” thread to return before exiting, thus making sure that only one thread can initialize the POSIX threads library. (Bug#42850)
pthread_cond_wait() implementations for
Windows could deadlock in some rare circumstances.
Debug builds could not be compiled with the Sun Studio compiler. (Bug#47474)
Solaris binary packages now are compiled with
-g0 rather than
ARCHIVE storage engine lost
records during a bulk insert.
When creating a new instance on Windows using
mysqld-nt and the
--install parameter, the value of the service
would be set incorrectly, resulting in a failure to start the
The server crashed when re-using outer column references in correlated subqueries when the enclosing query used a temp table. (Bug#46791)
Assertion failure could result from repeated execution of a stored procedure containing an incorrect query with a subselect. (Bug#46629)
An attempt to create a table with the same name as an existing view could cause a server crash. (Bug#46384)
A parser problem prevented properly stripping backquotes from an
argument to a user-defined function (UDF). If the UDF was in an
ORDER BY clause, its name would not be
properly resolved against an alias with the same name in the
InnoDB table that used an unknown
collation (created on a different server, for example) caused a
InnoDB did not disallow creation of an index
with the name
GEN_CLUST_INDEX, which is used
CREATE TEMPORARY TABLE failed for
InnoDB tables on systems with
case-insensitive file systems when
= 2 and the pathname of the temporary file
directory contained uppercase characters.
When re-installing MySQL on Windows on a server that has a data
directory from a previous MySQL installation, the installer
would fail to identify the existence of the installation and the
password configured for the
Client flags were incorrectly initialized for the embedded
server, causing several tests in the
suite to fail.
InnoDB did not always disallow creating
tables containing columns with names that match the names of
internal columns, such as
See also Bug#18360.
InnoDB use of
cause a crash when MySQL data dictionaries went out of sync.
Selecting from the process list in the embedded server caused a crash. (Bug#43733)
See also Bug#47304.
A test for stack growth failed on some platforms, leading to server crashes. (Bug#42213)
The server used the wrong lock type (always
TL_READ instead of
TL_READ_NO_INSERT when appropriate) for
tables used in subqueries of
UPDATE statements. This led in
some cases to replication failure because statements were
written in the wrong order to the binary log.
The mysql-stress-test.pl test script was
missing from the
noinstall packages on
When using the
SHOW TABLE STATUS displayed incorrect
When building MySQL on Windows from source, the
WITH_BERKELEY_STORAGE_ENGINE option would
fail to configure
BDB support correctly.