Re: Fixing "the worst InnoDB corruption bug in 3 years" - when

[Heikki Tuuri]

Bruce,
5.0.3 is the next in line. I am not sure whether 4.0.9 comes after that.
You should consider buying a MySQL support contract. MySQL Gold and Platinum 
Premier Support customers are entitled to custom builds:
http://www.mysql.com/support/premier.html

Best regards,
Heikki Tuuri
Innobase Oy
Foreign keys, transactions, and row level locking for MySQL
InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM 
tables
http://www.innodb.com/order.php

Order MySQL technical support from https://order.mysql.com/
----- Original Message ----- 
From: "Bruce Dembecki" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Thursday, December 30, 2004 9:51 AM
Subject: Re: Fixing "the worst InnoDB corruption bug in 3 years" - when


Thanks Heikki, I understand the bug, and I know you fixed it, for which I 
a=
m
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 
hand=
s
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 
bi=
t
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,
=20
It is the bug "innodb_file_per_table corrupts secondary indexes".
=20
I fixed it with several changesets on Sunday:
=20
http://lists.mysql.com/internals
=20
Thus, it is fixed in the current 4.1 bk tree.
=20
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 
man=
y
are running with innodb_file_per_table.
=20
Regards,
=20
Heikki
=20
=20
On 12/28/04 2:38 PM, "Bruce Dembecki" <[EMAIL PROTECTED]> wrote:
In the MySQL Manual under InnoDB in the "Using Per-Table Tablespace" 
sec=
tion
it says clearly at the top:
=20
NOTE: CRITICAL BUG in 4.1 if you specify innodb_file_per_table in 
`my.cn=
f'!
If you shut down mysqld, then records may disappear from the secondary
indexes of  a table. See (Bug #7496) for more information and 
workaround=
s.
=20
Following the link to Bug 7496 (http://bugs.mysql.com/bug.php?id=3D7496) 
w=
e are
told two important things:
=20
1. This is the worst InnoDB corruption bug in 3 years.
2. Will be fixed in 4.1.9.
=20
So thanks to Heikki for finding and fixing this.
So now to the question...
=20
As a person in the process of migrating from 4.0 to 4.1 and having 
alrea=
dy
scheduled the downtime with my clients for this Friday morning, and 
havi=
ng to
do a full dump and import already as part of the migration process I'd 
l=
ike
to  know WHEN the fix will be available. I don=B9t have a lot of 
opportuni=
ties
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.
=20
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.
=20
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 
i=
s to
only use MySQL official binaries in production.
=20
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]


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]