Hi!
InnoDB is the MySQL table type that supports FOREIGN KEY constraints, row-level locking, Oracle-style consistent, non-locking SELECTs, multiple tablespaces, and a non-free online hot backup tool.
Release 4.1.7 is mainly a bugfix release. It is the first in the 4.1 series that has been labeled 'production', but since quite a few bugs were fixed in both 4.1.6 and 4.1.7, I would still wait for a few weeks to see if there are any critical bugs in 4.1.7.
Functionality added or changed:
* Made LOCK TABLES behave by default like it did before MySQL 4.0.20 or 4.1.2: no InnoDB lock will be taken. Added a startup option and settable system variable innodb_table_locks for making LOCK TABLE acquire also InnoDB locks. See section 16.17 Restrictions on InnoDB Tables. (Bug #3299, Bug #5998)
* SHOW TABLE STATUS now shows the creation time of the table for InnoDB. Note that this timestamp might not be the correct time because, e.g., ALTER TABLE changes this timestamp.
* If innodb_thread_concurrency would be exceeded, let a thread sleep 10 ms before entering the FIFO queue; previously, the value was 50 ms.
Bugs fixed:
* Fixed problem introduced in MySQL 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. Bug surfaced when using the InnoDB innobackup script. (Bug #5949)
* 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 operation. This caused a notorious 'Long semaphore wait' message to be printed to the `.err' log. (Bug #5961)
Upgrading to 4.1.7:
* If you have created or used InnoDB tables with TIMESTAMP columns in MySQL versions 4.1.0-4.1.3, you have to rebuild those tables when you upgrade to MySQL-4.1.4 or later. The storage format in those MySQL versions for a TIMESTAMP column was wrong. If you upgrade from 4.0 to 4.1.4 or later, then no rebuild of TIMESTAMP tables is needed.
* If you have stored characters < ASCII(32) to non-latin1 non-BINARY indexed columns in MySQL versions <= 4.1.2, then you have to rebuild those tables after you upgrade to >= 4.1.3. The reason is that the sorting order of those characters and the space character changes for some character sets in 4.1.3. See the MySQL/InnoDB-4.1.3 changelog for a precise description of the cases where you need to rebuild the table. Also MyISAM tables have to be rebuilt or repaired in these cases.
* If you have used column prefix indexes on UTF-8 columns or other multibyte character set columns in 4.1.0 - 4.1.5, you have to rebuild the tables when you upgrade to 4.1.6 or later.
* If you have used accent characters (ASCII codes >= 128) in database names, table names, constraint names, or column names in versions < 4.1, you cannot upgrade to 4.1 directly, because 4.1 uses UTF-8 to store metadata names. Use RENAME TABLE to overcome this if the accent character is in the table name or the database name, or rebuild the table.
Best regards,
Heikki Tuuri Innobase Oy http://www.innodb.com
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
