Message-ID: <40FF1D88.30404@coretech.co.nz>
Date: Thu, 22 Jul 2004 13:51:04 +1200
From: Mark Kirkwood <markir@coretech.co.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: [HACKERS] Point in Time Recovery
References: <200407132242.i6DMgg612564@candle.pha.pa.us>	
	<1089760416.17493.3327.camel@stromboli>	
	<40F49AE9.2060805@familyhealth.com.au>
	<1089789682.17493.3890.camel@stromboli>
In-Reply-To: <1089789682.17493.3890.camel@stromboli>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Here is one for the 'idiot proof' category:

1) initdb and set archive_command
2) shutdown
3) do a backup
4) startup and run some transactions
5) shutdown and remove PGDATA
6) restore backup
7) startup

Obviously this does not work as the backup is performed with the 
database shutdown.

This got me wondering for 2 reasons:

1) Some alternative database servers *require* a procedure like this to 
enable their version of PITR - so the potential foot-gun thing is there.

2) Is is possible to make the recovery kick in even though pg_control 
says the database state is shutdown?

Simon Riggs wrote:

>
>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)
>
>
>  
>