List:General Discussion« Previous MessageNext Message »
From:Heikki Tuuri Date:October 30 2004 7:20am
Subject:MySQL/InnoDB-4.0.22 is released
View as plain text  
Hi!

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 
into 4.0.21.

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.

Bugs fixed:

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

Best regards,

Heikki Tuuri
Innobase Oy
http://www.innodb.com

Thread
MySQL/InnoDB-4.0.22 is releasedHeikki Tuuri30 Oct