InnoDB Plugin Notes
InnoDB Plugin has been upgraded to version
1.0.8. This version is considered of General Availability (GA)
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 generic ia64.
Functionality Added or Changed
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).
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, CVE-2010-1849)
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
In MySQL 5.0 and above, this permitted an authenticated user
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
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, CVE-2010-1848)
The server was susceptible to a buffer-overflow attack due to a
failure to perform bounds checking on the table name argument of
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, CVE-2010-1850)
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.
Important Change; Replication:
CHANGE MASTER TO
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
MASTER TO, this information includes the previous
GLOBAL sql_slave_skip_counter, this information
includes the previous values of
(Bug #43406, Bug #43407)
The values of
innodb_buffer_pool_pages_misc in the
information_schema.global_status table could
be computed incorrectly.
InnoDB Plugin 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. Now the check is only done when
innodb_strict_mode is enabled
or if the table is dynamic or compressed.
A mismatch between index information maintained within the
.frm files and the corresponding information
in the InnoDB system tablespace could produce this error:
n columns unique inside InnoDB, but
MySQL is asking statistics for
columns. Have you mixed up .frm files from different
Connections waiting for an
InnoDB row lock
KILL until the row lock
wait ended. Now,
KILL during lock
wait results in “query interrupted” instead of
“lock wait timeout exceeded”. The corresponding
transaction is rolled back.
An overly strict assertion could fail during the purge of
delete-marked records in
InnoDB tables that contain column
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
InnoDB stores locally any
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
formats, because there
always stores locally columns having a length up to
local_len = 788 bytes.
InnoDB page splitting could enter
an infinite loop for compressed tables.
The failure of a
was logged with the wrong error code, causing replication slaves
to stop even when the failure was expected on the master.
For updates to
TIMESTAMP columns could be
updated even when no values actually changed.
Storage engine plugins on Windows could've been built with a
time_t which was different from
the server expectations. The difference could cause affected
plugins to crash. In addition, the use of the
time_t type in the storage engine API layer
has been enforced.
(Bug #39802, Bug #40092)
UNINSTALL PLUGIN to
remove a loaded plugin, open tables and connections caused
mysqld to hang until the open connections had
1) In rare cases, if a thread was interrupted during a
PRIVILEGES operation, a debug assertion occurred later
due to improper diagnostics 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.
to an empty string failed to clear the current debug settings.
Certain path names passed to
LOAD_FILE() could cause a server
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)
Locking involving the
LOCK_status mutexes could deadlock.
InnoDB fast index creation could
incorrectly use a table copy in some cases.
On Windows, the server failed to find a description for Event ID 100. (Bug #48042)
A syntactically invalid trigger could cause the server to crash when trying to list triggers. (Bug #50755)
A memory leak occurred due to missing deallocation of the
comparators array (a member of the
EXPLAIN could cause a server
crash for some queries with subqueries.
In MySQL 5.1,
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.
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.
mysqld_safe did not always pass
to mysqld. mysqld_safe did
not treat dashes and underscores as equivalent in option names.
InnoDB could fail to create a unique index on
--secure-file-priv to the
empty string left the value unaffected.