InnoDB Plugin Notes
InnoDB Plugin has been upgraded to version
1.0.10. This version is considered of General Availability (GA)
quality.
In this release, the InnoDB Plugin is
included in source and binary distributions, except RHEL3,
RHEL4, SuSE 9 (x86, x86_64, ia64), generic Linux RPM packages,
and any builds produced with the icc
compiler. It also does not work for FreeBSD 6 and HP-UX or for
Linux on generic ia64.
Functionality Added or Changed
InnoDB:
The mechanism that checks if there is enough space for redo logs
was improved, reducing the chance of encountering this message:
ERROR: the age of the last checkpoint is
.
(Bug #39168)x, which exceeds the log group
capacity y
Bugs Fixed
Security Fix; InnoDB:
After changing the values of the
innodb_file_format or
innodb_file_per_table configuration
parameters, DDL statements could cause a server crash.
(Bug #55039, CVE-2010-3676)
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, CVE-2010-3683)
Security Fix:
Using EXPLAIN with queries of the
form SELECT ... UNION ... ORDER BY (SELECT ... WHERE
...) could cause a server crash.
(Bug #52711, CVE-2010-3682)
Security Fix:
The server could crash if there were alternate reads from two
indexes on a table using the
HANDLER interface.
(Bug #54007, CVE-2010-3681)
Security Fix:
Use of TEMPORARY
InnoDB tables with nullable columns
could cause a server crash.
(Bug #54044, CVE-2010-3680)
Security Fix:
A malformed argument to the
BINLOG statement could result in
Valgrind warnings or a server crash.
(Bug #54393, CVE-2010-3679)
Security Fix:
Incorrect handling of NULL arguments could
lead to a crash for IN() or
CASE operations when
NULL arguments were either passed explicitly
as arguments (for IN()) or
implicitly generated by the WITH ROLLUP
modifier (for IN() and
CASE).
(Bug #54477, CVE-2010-3678)
Security Fix:
Joins involving a table with a unique
SET column could cause a server
crash.
(Bug #54575, CVE-2010-3677)
Security Fix: A security bug was fixed. (Bug #52315)
Security Fix: A security bug was fixed. (Bug #53933)
InnoDB:
Performing large numbers of RENAME
TABLE statements caused excessive memory use.
(Bug #47991)
InnoDB:
Fast index creation in the InnoDB Plugin
could fail, leaving the new secondary index corrupted.
(Bug #54330)
InnoDB:
InnoDB could issue an incorrect message on
startup, if tables were created under the setting
innodb_file_per_table=ON. The message was of
the form InnoDB: Warning: allocated tablespace
. If
you encounter this message after upgrading, create an
n, old maximum was 0InnoDB table with
innodb_file_per_table = ON and restart the
server. The message should not be displayed any more. If you
continue to encounter this message, or if you get it and haven't
used a version without this fix, you might have corruption in
your shared tablespace. If so, back up and reload your data.
(Bug #54658)
InnoDB:
An ALTER TABLE statement could
convert an InnoDB compressed table (with
row_format=compressed) back to an
uncompressed table (with row_format=compact).
(Bug #54679)
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)
Replication: Two related issues involving temporary tables and transactions were introduced by a fix made in MySQL 5.1.37:
When a temporary table was created or dropped within a
transaction, any failed statement that following the
CREATE
TEMPORARY TABLE or
DROP TEMPORARY
TABLE statement triggered a rollback, which caused
the slave to diverge from the master.
When a CREATE
TEMPORARY TABLE ... SELECT * FROM ... statement
was executed within a transaction in which only tables using
transactional storage engines were used and the transaction
was rolled back at the end, the changes—including the
creation of the temporary table—were not written to
the binary log.
The current fix restores the correct behavior in both of these cases. (Bug #53560)
References: This bug was introduced by Bug #43929.
Replication:
When CURRENT_USER() or
CURRENT_USER was used to supply
the name and host of the affected user or of the definer in any
of the statements DROP USER,
RENAME USER,
GRANT,
REVOKE, and
ALTER EVENT, the reference to
CURRENT_USER() or
CURRENT_USER was not expanded
when written to the binary log. This resulted in
CURRENT_USER() or
CURRENT_USER being expanded to
the user and host of the slave SQL thread on the slave, thus
breaking replication. Now
CURRENT_USER() and
CURRENT_USER are expanded prior
to being written to the binary log in such cases, so that the
correct user and host are referenced on both the master and the
slave.
(Bug #48321)
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:
FLUSH LOGS
could in some circumstances crash the server. This occurred
because the I/O thread could concurrently access the relay log
I/O cache while another thread was performing the
FLUSH LOGS,
which closes and reopens the relay log and, while doing so,
initializes (or re-initializes) its I/O cache. This could cause
problems if some other thread (in this case, the I/O thread) is
accessing it at the same time.
Now the thread performing the
FLUSH LOGS
takes a lock on the relay log before actually flushing it.
(Bug #53657)
References: See also Bug #50364.
The make_binary_distribution target to
make could fail on some platforms because the
lines generated were too long for the shell.
(Bug #54590)
mysqld could fail during execution when using SSL. (Bug #34236)
Builds of the embedded mysqld failed due to a
missing element of the struct NET.
(Bug #53908, Bug #53912)
The definition of the MY_INIT macro in
my_sys.h included an extraneous semicolon,
which could cause compilation failure.
(Bug #53906)
Valgrind warnings in the InnoDB
compare_record() function were corrected.
(Bug #38999)
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)
The Lock_time value in the slow query log was
negative for stored routines.
(Bug #53191)
A client with automatic reconnection enabled saw the error
message Lost connection to MySQL server during
query if the connection was lost between the
mysql_stmt_prepare() and
mysql_stmt_execute() C API
functions. However,
mysql_stmt_errno() returned 0,
not the corresponding error number 2013.
(Bug #53899)
The server failed to disregard sort order for some zero-length tuples, leading to an assertion failure. (Bug #54459)
The default value of
myisam_max_extra_sort_file_size could be
higher than the maximum accepted value, leading to warnings upon
the server start.
(Bug #54457)
If a session tried to drop a database containing a table opened
with HANDLER in another session,
any DATABASE statement
(CREATE, DROP,
ALTER) executed by that session produced a
deadlock.
(Bug #54360)
Sort-index_merge for join tables other than
the first table used excessive memory.
(Bug #41660)
Queries that used MIN() or
MAX() on indexed columns could be
optimized incorrectly.
(Bug #53859)
The results of some ORDER BY ... DESC queries
were sorted incorrectly.
(Bug #51431)
Index Merge between three indexes could
return incorrect results.
(Bug #50389)
A signal-handler redefinition for SIGUSR1 was
removed. The redefinition could cause the server to encounter a
kernel deadlock on Solaris when there are many active threads.
Other POSIX platforms might also be affected.
(Bug #54667)
Inconsistent checking of the relationship between
SHOW statements and
INFORMATION_SCHEMA queries caused such
queries to fail sometimes.
(Bug #54422)
The behavior of the RPM upgrade installation has changed. During
an upgrade installation using the RPM packages, if the MySQL
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 upgrade. 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)
