Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <429CECBA.4040804@sbcglobal.net>
Date: Tue, 31 May 2005 16:01:14 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Identifer 200 not registered
References: <429CCDF2.2060408@debrunners.com>
In-Reply-To: <429CCDF2.2060408@debrunners.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To reproduce this you will need the recovery system to encounter at
reboot time the datatype that you are interested in.  This takes a
reboot of the database, which is usually done in the testing system
by having a suite with multiple tests.  The first test sets up the
database, and then the second test operates on the same database.

In this case the first test probably needs an index with a decimal
key.  Then open a transaction and insert enough rows to be sure that
the log records have made it to disk, and then crash the server.  I
think if you make sure to log more than 64k of data you should be
safe.  Then crash the server without committing the transaction.

This should insure that recovery should see the datatype you are
interested in during the undo processing.

I think you need undo, as redo is physical so I don't think needs the
format identifier to be registered.

storerecovery in the suites directory is an example of a recovery
test suite.

Daniel John Debrunner wrote:

> A week or so ago there was some discussion of a problem with recovery
> and format identifier 200 not being registered.
> 
> That's a problem with one of my changes and I have a quick fix but was
> there a way to reproduce this? I can't remember who had the problem.
> 
> Thanks,
> Dan.
> 
>