X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 0C4D6D1B266;
	Wed, 14 Jul 2004 04:21:30 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 93154-02; Wed, 14 Jul 2004 07:21:32 +0000 (GMT)
Received: from cmailg4.svr.pol.co.uk (cmailg4.svr.pol.co.uk [195.92.195.174])
	by svr1.postgresql.org (Postfix) with ESMTP id 4971AD1B1A5;
	Wed, 14 Jul 2004 04:21:23 -0300 (ADT)
Received: from modem-2065.lemur.dialup.pol.co.uk ([217.135.136.17]
	helo=[192.168.0.100]) by cmailg4.svr.pol.co.uk with esmtp (Exim 4.14)
	id 1Bke4x-0002rr-B9; Wed, 14 Jul 2004 08:21:23 +0100
Subject: Re: [HACKERS] Point in Time Recovery
From: Simon Riggs <simon@2ndquadrant.com>
To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
	Klaus Naumann <kn@mgnet.de>, markw@osdl.org,
	Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org,
	pgsql-admin@postgresql.org
In-Reply-To: <40F49AE9.2060805@familyhealth.com.au>
References: <200407132242.i6DMgg612564@candle.pha.pa.us>
	<1089760416.17493.3327.camel@stromboli>
	<40F49AE9.2060805@familyhealth.com.au>
Content-Type: text/plain
Organization: 2nd Quadrant
Message-Id: <1089789682.17493.3890.camel@stromboli>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Wed, 14 Jul 2004 08:21:22 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.1 tagged_above=0.0 required=5.0 tests=RCVD_IN_SORBS
X-Spam-Level: 
X-Archive-Number: 200407/161
X-Sequence-Number: 14229

On Wed, 2004-07-14 at 03:31, Christopher Kings-Lynne wrote:
> Can you give us some suggestions of what kind of stuff to test?  Is 
> there a way we can artificially kill the backend in all sorts of nasty 
> spots to see if recovery works?  Does kill -9 simulate a 'power off'?
> 

I was hoping some fiendish plans would be presented to me...

But please start with "this feels like typical usage" and we'll go from
there...the important thing is to try the first one.

I've not done power off tests, yet. They need to be done just to
check...actually you don't need to do this to test PITR...

We need to exhaustive tests of...
- power off
- scp and cross network copies
- all the permuted recovery options
- archive_mode = off (i.e. current behaviour)
- deliberately incorrectly set options (idiot-proof testing)

I'd love some help assembling a test document with numbered tests...

Best regards, Simon Riggs