InnoDB Plugin has been upgraded to version 1.0.8. 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), and generic Linux RPM packages. It also does not work for FreeBSD 6 and HP-UX or for Linux on generic ia64.

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). (Bug#53122)

Security Fix: 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 COM_FIELD_LIST.

In MySQL 5.0 and above, this permitted an authenticated user with 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 user with DELETE or 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)

Security Fix: The server was susceptible to a buffer-overflow attack due to a failure to perform bounds checking on the table name argument of a 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)

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)

Important Change: Replication: When invoked, CHANGE MASTER TO and SET GLOBAL 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 CHANGE MASTER TO, this information includes the previous values for MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET GLOBAL sql_slave_skip_counter, this information includes the previous values of sql_slave_skip_counter, the group relay log name, and the group relay log position. (Bug#43406, Bug#43407)

Replication: The failure of a REVOKE statement was logged with the wrong error code, causing replication slaves to stop even when the failure was expected on the master. (Bug#51987)

Certain path names passed to LOAD_FILE() could cause a server crash. (Bug#53417)

When reporting a foreign key constraint violation during INSERT, InnoDB could display uninitialized data for the DB_TRX_ID and DB_ROLL_PTR system columns. (Bug#53202)

The values of innodb_buffer_pool_pages_total and innodb_buffer_pool_pages_misc in the information_schema.global_status table could be computed incorrectly. (Bug#52983)

InnoDB page splitting could enter an infinite loop for compressed tables. (Bug#52964)

An overly strict assertion could fail during the purge of delete-marked records in DYNAMIC or COMPRESSED InnoDB tables that contain column prefix indexes. (Bug#52746)

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 DYNAMIC and COMPRESSED formats, InnoDB stores locally any non-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 REDUNDANT and COMPACT formats, because there InnoDB always stores locally columns having a length up to local_len = 788 bytes. (Bug#52745)

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 that was designed with the assumption that semi-consistent read would be only attempted on table scans, failed. (Bug#52663)

Setting @@GLOBAL.debug to an empty string failed to clear the current debug settings. (Bug#52629)

A memory leak occurred due to missing deallocation of the comparators array (a member of the Arg_comparator class). (Bug#52124)

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)

Connections waiting for an InnoDB row lock ignored 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. (Bug#51920)

Locking involving the LOCK_plugin, LOCK_global_system_variables, and LOCK_status mutexes could deadlock. (Bug#51591)

InnoDB fast index creation could incorrectly use a table copy in some cases. (Bug#50946)

A syntactically invalid trigger could cause the server to crash when trying to list triggers. (Bug#50755)

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. (Bug#50495)

Setting --secure-file-priv to the empty string left the value unaffected. (Bug#50373)

In MySQL 5.1, READ COMMITTED was changed to use less locking due to the availability of row based binary logging (see the Note under READ COMMITTED at Section 12.3.6, “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. (Bug#48607)

EXPLAIN could cause a server crash for some queries with subqueries. (Bug#48419)

On Windows, the server failed to find a description for Event ID 100. (Bug#48042)

For updates to InnoDB tables, TIMESTAMP columns could be updated even when no values actually changed. (Bug#47453)

mysqld_safe did not always pass --open-files-limit through to mysqld. mysqld_safe did not treat dashes and underscores as equivalent in option names. (Bug#47095)

If the server is started with --skip-grant-tables, plugin loading and unloading should be prohibited, but the server failed to reject INSTALL PLUGIN and UNINSTALL PLUGIN statements. (Bug#46261)

A mismatch between index information maintained within the .frm files and the corresponding information in the InnoDB system tablespace could produce this error: [ERROR] Index index of table has n columns unique inside InnoDB, but MySQL is asking statistics for m columns. Have you mixed up .frm files from different installations? (Bug#44571)

InnoDB could fail to create a unique index on NULL columns. (Bug#41904)

Storage engine plugins on Windows could've been built with a definition of 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)

When using UNINSTALL PLUGIN to remove a loaded plugin, open tables and connections caused mysqld to hang until the open connections had been closed. (Bug#39053)

1) In rare cases, if a thread was interrupted during a FLUSH 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. (Bug#33982)