Bruce,
it is the bug "innodb_file_per_table corrupts secondary indexes".
I fixed it with several changesets on Sunday:
http://lists.mysql.com/internals
Thus, it is fixed in the current 4.1 bk tree.
This is indeed the worst InnoDB corruption bug since the BLOB update bug of summer 2001. Fortunately, the bug affects few users, because not too many are running with innodb_file_per_table.
Regards,
Heikki
.............. List: mysql Subject: Fixing "the worst InnoDB corruption bug in 3 years" - when From: Bruce Dembecki <bruce () liveworld ! com> Date: 2004-12-28 22:38:36 Message-ID: <BDF7206C.29024%bruce () liveworld ! com> [Download message RAW]
In the MySQL Manual under InnoDB in the "Using Per-Table Tablespace" section it says clearly at the top:
NOTE: CRITICAL BUG in 4.1 if you specify innodb_file_per_table in `my.cnf'! If you shut down mysqld, then records may disappear from the secondary indexes of a table. See (Bug #7496) for more information and workarounds.
Following the link to Bug 7496 (http://bugs.mysql.com/bug.php?id=7496) we are told two important things:
1. This is the worst InnoDB corruption bug in 3 years. 2. Will be fixed in 4.1.9.
So thanks to Heikki for finding and fixing this.
So now to the question...
As a person in the process of migrating from 4.0 to 4.1 and having already scheduled the downtime with my clients for this Friday morning, and having to do a full dump and import already as part of the migration process I'd like to know WHEN the fix will be available. I donšt have a lot of opportunities for a full dump and import, so this is a crucial time for me, and there are some benefits with innodb_file_per_table that are important to us.
If we go with history then we should expect a new version of the current MySQL products every 2 months approximately. Having just received 4.1.8 I'd not like to see MySQL leave InnoDB's worst corruption bug in three years sit for two months when a fix has already been written.
Can we have a new build with this fix included please? When can we have it? The "grab it from the nightly snapshots and compile it yourself" answer won't cut it when we have to deploy into production and MySQL's company line is to only use MySQL official binaries in production.
If not 4.1.9 can we call it 4.1.8b and get it shipped (there's already a 4.1.8a).
Best regards, Bruce
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
