Thanks Heikki, I understand the bug, and I know you fixed it, for which I am very pleased, as always problems when identified are fixed quickly :-)
I guess the question I was trying to ask of MySQL is when will 4.1.9 be built... It's very frustrating knowing that a problem has been fixed (particularly a serious problem such as this) but having to sit on our hands and wait perhaps two months for a MySQL "Official" Binary to be built. Heikki you have definitely done your part in finding and fixing this thing rapidly. I understand MySQL doesn't want to make new releases every week, they need to set some guidance for their users that their releases will not be made too frequently. On the other hand this isn't something that is a bit annoying, or some queries don't work... This corrupts the database. We can't grab a snapshot and compile our own version (well we could), because if we do it won't be a "MySQL Official Binary" and if we have problems with the database our clients wouldn't understand why we weren't using a MySQL sanctioned version. On the other hand if we do use the Official binary, our data will become corrupt. The problem I am experiencing is not the delay in fixing the problem, but the delay in releasing the fix. The two month between releases that seems common at the moment isn't unreasonable in most cases, except where there's a corrupting bug uncovered and fixed, right after a release - February is too long to wait for this fix to be included in an official binary. In my mind (as I am directly affected by this bug) this one is serious enough to release a new build asap. As a side note with demonstrated performance increases when using innodb_file_per_table why aren't more people using it? Best Regards, Bruce On 12/29/04 10:22 PM, Heikki Tuuri wrote: > 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 > > > On 12/28/04 2:38 PM, "Bruce Dembecki" <[EMAIL PROTECTED]> wrote: > >> 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]
