Hi! InnoDB is a MySQL table type which supports transactions, row level locking, foreign keys, and a non-free hot backup tool. InnoDB is included in all downloads of MySQL-4.0. Of the commercially licensed versions, MySQL-Pro contains InnoDB.
Release 4.0.5 contains a feature which application programmers will find useful when porting applications from Oracle to MySQL. InnoDB now supports two new transaction isolation levels: READ UNCOMMITTED and READ COMMITTED. The default is REPEATABLE READ, like before. In the READ COMMITTED level each consistent read SELECT reads a new snapshot of the database, as seen at the start of the SELECT statement. Thus, it is not necessary to COMMIT the transaction to get a fresh snapshot of the database in a consistent read. This is how consistent read works in Oracle. In the READ COMMITTED level, locking reads SELECT ... LOCK IN SHARE MODE and ... FOR UPDATE only lock the records themselves and do not set next-key locks. Thus, new inserts by other users are allowed, even if a user would have locked every row in the table with SELECT ... FOR UPDATE. Also this behavior is like in Oracle, and helps to prevent deadlocks in applications. The READ COMMITTED level still differs from Oracle in non-unique range UPDATE and DELETE: since the MySQL binlogging requires that 'phantom rows' must not appear in these operations, they use regular next-key locking. If InnoDB can retrieve a unique record in an UPDATE, DELETE, or a locking read SELECT using a UNIQUE index, then InnoDB-4.0.5 only locks the record itself and does not set a next-key lock. This holds in all isolation levels and helps to reduce deadlocks in all applications. An unfortunate bug in REPLACE and AUTO_INCREMENT was introduced to 4.0.4, and the fix did not make it to 4.0.5. The fix will be in 4.0.6. Lenz will post another changelog which contains other MySQL changes in 4.0.5. The full changelog of InnoDB-4.0.5: * InnoDB now supports also transaction isolation levels READ COMMITTED and READ UNCOMMITTED. READ COMMITTED more closely emulates Oracle and makes porting of applications from Oracle to MySQL easier. * Deadlock resolution is now selective: we try to pick as victims transactions with less modified or inserted rows. * FOREIGN KEY definitions are now aware of the lower_case_table_names setting in my.cnf. * SHOW CREATE TABLE does not output the database name to a FOREIGN KEY definition if the referred table is in the same database as the table. * InnoDB does a consistency check to most index pages before writing them to a data file. * If you set innodb_force_recovery > 0, InnoDB tries to jump over corrupt index records and pages when doing SELECT * FROM table. This helps in dumping. * InnoDB now again uses asynchronous unbuffered i/o in Windows 2000 and XP, but not in NT, 95/98/ME. * Fixed a bug: the InnoDB range estimator greatly exaggerated the size of a short index range if the paths to the endpoints of the range in the index tree happened to branch already in the root. This could cause unnecessary table scans in SQL queries. The fix will also be backported to 3.23.54. * Fixed a bug present in 3.23.52, 4.0.3, 4.0.4: InnoDB startup could take very long or even crash on some Win 95/98/ME computers. * Fixed a bug: the AUTO-INC lock was held to the end of the transaction if it was granted after a lock wait. This could cause unnecessary deadlocks. * Fixed a bug: if SHOW INNODB STATUS, innodb_monitor, or innodb_lock_monitor had to print several hundred transactions in one report, and the output became truncated, InnoDB would hang, printing to the error log many waits for a mutex created at srv0srv.c, line 1621. * Fixed a bug: the SQL statement SHOW INNODB STATUS on Unix always reported average file read size as 0 bytes. * Fixed a potential bug in 4.0.4: InnoDB now does ORDER BY ... DESC like MyISAM. * Fixed a bug: DROP TABLE could cause crash or a hang if there was a rollback concurrently running on the table. The fix will only be backported to 3.23 if this appears a real problem for users. * Fixed a bug: ORDER BY could fail if you had not created a primary key to a table, but had defined several indexes of which at least one was a UNIQUE index with all its columns declared as NOT NULL. * Fixed a bug: a lock wait timeout in connection with ON DELETE CASCADE could cause corruption in indexes. * Fixed a bug: if a SELECT was done with a unique key from a primary index, and the search matched to a delete-marked record, InnoDB could erroneously return the NEXT record. * Outstanding bugs: in 4.0.4 two bugs were introduced to AUTO_INCREMENT. REPLACE can cause the counter to be left 1 too low. A deadlock or a lock wait timeout can cause the same problem. Best regards, Heikki Tuuri Innobase Oy http://www.innodb.com --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
