InnoDB Plugin Notes:
This release includes
InnoDB Plugin 1.0.6.
This version is considered of Release Candidate (RC) quality.
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.
Functionality added or changed:
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
When used on partitioned tables, the
records_in_range handler call checked more
partitions than necessary. The fix for this issue reduces the
number of unpruned partitions checked for statistics in
partition range checking, which has resulted in some partition
operations being performed up to 2-10 times faster than before
this change was made, when testing with tables having 1024
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, CVE-2009-4484)
Important Change: Replication:
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
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
SELECT; if the master and the slave retrieved rows in
different order, they began to diverge.
A query that searched on a
ucs2 column failed
if the table was partitioned.
INFILE statement that loaded data into a table having
a column name that had to be escaped (such as
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.
See also Bug#47927.
Replication: Spatial data types caused row-based replication to crash. (Bug#48776)
Replication: A flaw in the implementation of the purging of binary logs could result in orphaned files being left behind in the following circumstances:
If the server failed or was killed while purging binary logs.
If the server failed or was killed after creating of a new binary log when the new log file was opened for the first time.
In addition, if the slave was not connected during the purge operation, it was possible for a log file that was in use to be removed; this could lead data loss and possible inconsistencies between the master and slave. (Bug#45292)
When using the
MIXED logging format, the statements
LOAD DATA CONCURRENT
LOCAL INFILE and
LOAD DATA CONCURRENT
INFILE were logged as
LOAD DATA LOCAL
LOAD DATA LOCAL
INFILE, respectively (in other words, the
CONCURRENT keyword was omitted). As a result,
when using replication with either of these logging modes,
queries on the slaves were blocked by the replication SQL thread
while trying to execute the affected statements.
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)
IBMDB2I storage engine was
missing from the i5os 64-bit distribution of MySQL 5.1.42. It is
now included again.
push_warning_printf() function was being
called with an invalid error level
MYSQL_ERROR::WARN_LEVEL_ERROR, causing an
assertion failure. To fix the problem,
MYSQL_ERROR::WARN_LEVEL_ERROR has been
Some prepared statements could raise an assertion when re-executed. (Bug#49570)
A Valgrind error in
corrected. Thanks to Sergey Petrunya for the patch to fix this
When compiling on Windows, an error in the CMake definitions for
InnoDB would cause the engine to be built
Specifying an index algorithm (such as
indexes caused a server crash. These index types do not support
algorithm specification, and it is now disallowed to do so.
The optimizer sometimes incorrectly handled conditions of the
ENCODE() could be inefficient
because multiple executions within a single statement
reinitialized the random generator multiple times even with
MySQL 5.1 does not support 2-byte collation numbers, but did not check the number and crashed for out-of-range values. (Bug#49134)
check_key_in_view() was missing a
DBUG_RETURN in one code branch, causing a
crash in debug builds.
strmake() calls had an incorrect
length argument (too large by one).
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.
Re-execution of a prepared statement could cause a server crash. (Bug#48508)
An aliasing violation in the C API could lead to a crash. (Bug#48284)
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)
InnoDB Monitor could fail to print
diagnostic information after a long lock wait.
GROUP BY ... WITH ROLLUP
that did not use indexes could return incorrect results.
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)
On Solaris, no stack trace was printed to the error log after a crash. (Bug#47391)
It was possible for
not to initialize correctly.
using only the first
N bytes of the
column, even though column values could be longer than
N bytes if they contained multibyte
NULL values sometimes did not
produce a correct result.
Crash recovery did not work for
InnoDB temporary tables.
The mysql_upgrade command would create three
additional fields to the
db_collation), but did not populate the
fields with correct values. This would lead to error messages
reported during stored procedure execution.
MyISAM files were
opened, they were always memory mapped, sometimes causing
memory-swapping problems. To deal with this, a new system
myisam_mmap_size, was added to
limit the amount of memory used for memory mapping of
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
PRIVILEGES could cause a crash.