Hi! Buildmaster Lenz Grimmer of MySQL AB informed me that the last changeset in 4.0.7 was from Dec 20th, 2002.
That means that InnoDB-4.0.7 is essentially the same as InnoDB-4.0.6, and the changes listed below will only appear in MySQL-4.0.8! I apologize for the confusion. It was my error not to check the exact date of the source tree snapshot in 4.0.7. Despite this confusion, I wish a prosperous New Year to all MySQL/InnoDB users! Heikki Tuuri Innobase Oy http://www.innodb.com ----- Original Message ----- From: ""Heikki Tuuri"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Thursday, December 26, 2002 11:04 PM Subject: MySQL/InnoDB-4.0.7 is released > Hi! > > InnoDB is a MySQL table type which offers transactions, row level locking, > foreign key constraints, and a non-free hot backup tool. > > InnoDB is included in MySQL-Max-3.23 and all MySQL-4.0 downloads available > at http://www.mysql.com. > > MySQL AB decided to release MySQL-4.0.7 just a week after 4.0.6 to fix a > security issue in mysql_drop_db() in 4.0. > > InnoDB in 4.0.7 allows a user to define for a FOREIGN KEY constraints also > ON UPDATE actions. This new feature has been requested by several users > during the past year. > > As a special Christmas present you now have 4 % more free space in your > tablespace to use for storage of tables and indexes. That is possible > because the free space margin in InnoDB was reduced from 5 % to 1 % of the > tablespace size. No conversion of tables is needed. You get the bonus space > simply by upgrading to 4.0.7. > > > Full changelog: > > * InnoDB now supports also the SQL syntax FOREIGN KEY (...) REFERENCES > ...(...) [ON UPDATE CASCADE | ON UPDATE SET NULL | ON UPDATE RESTRICT | ON > UPDATE NO ACTION]. > > * Tables and indexes now reserve 4 % less space in the tablespace. Also > existing tables reserve less space. By upgrading to 4.0.7 you will see more > free space in "InnoDB free" in SHOW TABLE STATUS. > > * Fixed bugs: updating the PRIMARY KEY of a row would generate a foreign key > error on all FOREIGN KEYs which referenced secondary keys of the row to be > updated. Also, if a referencing FOREIGN KEY constraint only referenced the > first columns in an index, and there were more columns in that index, > updating the additional columns generated a foreign key error. > > * Fixed a bug: if an index contains some column twice, and that column is > updated, the table will become corrupt. From now on InnoDB prevents creation > of such indexes. > > * Fixed a bug: removed superfluous error 149 and and 150 printouts from the > .err log when a locking SELECT caused a deadlock or a lock wait timeout. > > > I wish a prosperous New Year to all MySQL/InnoDB users! > > 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 > --------------------------------------------------------------------- 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
