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.
Incompatible Change; Replication:
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
As part of the fix for this issue, any statement that causes a
trigger or function to update an
AUTO_INCREMENT column is now considered
unsafe for statement-based replication. For more information,
see Replication and
References: See also Bug #42415, Bug #48608, Bug #50440, Bug #53079.
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 option, if provided, no longer starts
and installs the server.
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).
This fix changes the method used to estimate the buffer size
required for each partition and limits the total buffer size to
a maximum of approximately 10 times
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)
References: See also Bug #45961, Bug #43729.
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)
Inserting negative values into an
AUTO_INCREMENT column of a partitioned table
could lead to apparently unrelated errors or a crash of the
This issue was observed in MySQL 5.1.31 and later only. (Bug #45823)
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)
References: 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.
TABLE ... DISABLE KEYS on a slave table caused
row-based replication to fail.
statements were not included in the output of
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).
As part of this fix, a mysql_upgrade option,
--write-binlog, is added. Its inverse,
--skip-write-binlog, can be used to disable
binary logging while the upgrade is in progress.
On the master, if a binary log event is larger than
max_allowed_packet, the error
is 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.
References: See also Bug #14068, Bug #47200, Bug #47303.
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.
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)
The mysql-stress-test.pl test script was
missing from the
noinstall packages on
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
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
ARCHIVE storage engine lost
records during a bulk insert.
Different invocations of
TABLE could return different results for a table
containing columns with spatial data types.
A test for stack growth failed on some platforms, leading to server crashes. (Bug #42213)
References: See also Bug #62856.
Assertion failure could result from repeated execution of a stored procedure containing an incorrect query with a subselect. (Bug #46629)
CONCAT_WS() could return
incorrect results due to an argument buffer also being used as a
myisamchk performed parameter value casting at startup that generated unnecessary warning messages. (Bug #33785)
HAVING clauses could hang
in an infinite loop.
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.
InnoDB tables, an unnecessary table
ALTER TABLE could
sometimes occur for metadata-only changes.
Attempts to enable
with a shared memory segment larger than 4GB caused a server
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
The server crashed when re-using outer column references in correlated subqueries when the enclosing query used a temp table. (Bug #46791)
An attempt to create a table with the same name as an existing view could cause a server crash. (Bug #46384)
Selecting from the process list in the embedded server caused a crash. (Bug #43733)
References: See also Bug #47304.
Client flags were incorrectly initialized for the embedded
server, causing several tests in the
suite to fail.
statements could raise an assertion.
socket system variable was
unavailable on Windows.
SHOW CREATE VIEW
were not being checked correctly.
INFILE statements were written to the binary log in
such a way that parsing problems could occur when re-executing
the statement from the log.
SELECT ... WHERE ... IN
(NULL, ...) was executed using a full table scan, even
if the same query without the
NULL used an
efficient range scan.
References: See also Bug #18360.
EXPLAIN caused a server crash for
certain valid queries.
The configure option
--without-server did not work.
Solaris binary packages now are compiled with
-g0 rather than
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)
On Mac OS X or Windows, sending a
signal to the server or an asynchronous flush (triggered by
flush_time) caused the server
a natural join and a mergeable view raised an assertion.
InnoDB did not disallow creation of an index
with the name
GEN_CLUST_INDEX, which is used
InnoDB table that used an unknown
collation (created on a different server, for example) caused a
InnoDB did not always disallow creating
tables containing columns with names that match the names of
internal columns, such as
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.
InnoDB use of
cause a crash when MySQL data dictionaries went out of sync.
When building MySQL on Windows from source, the
WITH_BERKELEY_STORAGE_ENGINE option would
fail to configure
BDB support correctly.
When using the
SHOW TABLE STATUS displayed incorrect