InnoDB is the MySQL table type that supports FOREIGN KEY constraints,
row-level locking, Oracle-style consistent, non-locking SELECTs, multiple
tablespaces (in 4.1), and a non-free online hot backup tool.
Release 4.0.22 is mainly a bugfix release of the stable 4.0 series. This
release fixes the unfortunate mysqldump --opt assertion failure that slipped
There are two new my.cnf options:
innodb_table_locks : By setting this to 0, you can get the LOCK TABLES
behavior that was used prior to 4.0.20. Old applications that use LOCK
TABLES in the AUTOCOMMIT=1 mode can easily end up in deadlocks if this is
set to 1, which is the default value.
innodb_max_purge_lag: Under bursts of a high UPDATE or DELETE load, you can
use this to force InnoDB to favor purge at the cost of users' SQL
statements. If the purge lags behind, the physical size of the database may
grow so that operation becomes disk-bound. To prevent that, it is better to
use this parameter to favor purge.
Functionality added or changed:
* New mysqld option --innodb-table-locks and session variable
innodb_table_locks (on by default). You can now disable InnoDB table locks
if your application depends on the way MySQL did table locks before 4.0.20.
(Bug #3299, Bug #5998)
* Added the startup option and settable global variable innodb_max_purge_lag
for delaying INSERT, UPDATE, and DELETE operations when the purge operations
are lagging. The default value of this parameter is zero, meaning that there
will not be any delays.
* Change error code to HA_ERR_ROW_IS_REFERENCED if we cannot DROP a parent
table because it is referenced by a FOREIGN KEY constraint.
* Fixed a bug introduced in 4.0.21. An assertion failed if one used
mysqldump with the option -l or --opt, or if one used LOCK TABLES ... LOCAL.
(Workaround in 4.0.21: use --quick and --single transaction. (Bug #5538)
* Make the check for excessive semaphore waits to tolerate glitches in the
system clock (do not crash the server if the system time is adjusted while
InnoDB is under load.). (Bug #5898)
* Fixed a bug in the InnoDB FOREIGN KEY parser that prevented ALTER TABLE of
tables containing # in their names. (Bug #5856)
* Fixed problem introduced in 4.0.21 where a connection starting a
transaction, doing updates, then FLUSH TABLES WITH READ LOCK, then COMMIT,
would cause replication slaves to stop complaining about error 1223. The bug
surfaced when using the InnoDB innobackup script. (Bug #5949)
* If one updated a column so that its size changed, or updated it to an
externally stored (TEXT or BLOB) value, then ANOTHER externally stored
column would show up as 512 bytes of good data + 20 bytes of garbage in a
consistent read that fetched the old version of the row. (Bug #5960)
* Release the dictionary latch during a long cascaded FOREIGN KEY operation,
so that we do not starve other users doing CREATE TABLE or other DDL
operations. This caused a notorious 'Long semaphore wait' message to be
printed to the .err log. (Bug #5961)
* Let InnoDB remember row locking type (X or S) inside LOCK TABLES, also
over plain consistent read SELECTs.
* Having a column prefix index in the primary key, and the same column fully
in a secondary key could cause an assertion failure in row_build_row_ref().
|• MySQL/InnoDB-4.0.22 is released||Heikki Tuuri||30 Oct|