Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 29 Jan 2009 11:35:27 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Record not found in some SQL - Bug?
In-reply-to: <4980C928.1030606@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <wjo87i4eflhs.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <21700110.post@talk.nabble.com> <21708823.post@talk.nabble.com>
 <4980BB45.4040203@sun.com> <21714590.post@talk.nabble.com>
 <4980C928.1030606@sun.com>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (usg-unix-v)

Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> jrgchip wrote:
>> Can you point me to information about that corruption bug?
>>   
> Please see the release notes for 10.3.3.0 (
> http://db.apache.org/derby/releases/release-10.3.3.0.cgi ) Detailed
> information can be found on the associated bug report:
> http://issues.apache.org/jira/browse/DERBY-3347 The symptoms in that
> bug report do not match your bug report but maybe the bug manifests
> itself in other ways. Upgrading to 10.3.3.0 will remove this theory
> from consideration.

Just to clarify, upgrading to 10.3.3.0 will not fix the corruption on an
existing database. Only recovery from an uncorrupted backup will do
that. But if it's data corruption, I don't think it's the same as
DERBY-3347 because

  1) DERBY-3347 only caused corruption on parts of the page, so it's
  very likely that we'd see a checksum error when reading the page from
  disk

  2) even if the checksum didn't detect the corruption, I think it's
  very unlikely that the exact same row should be affected both in the
  base table and in the index (as one experiment in DERBY-4032
  indicates) if this is DERBY-3347

-- 
Knut Anders