Re: [HACKERS] Point in Time Recovery - Mailing list pgsql-admin

From Mark Kirkwood
Subject Re: [HACKERS] Point in Time Recovery
Date
Msg-id 40FF1D88.30404@coretech.co.nz
Whole thread Raw
In response to Re: [HACKERS] Point in Time Recovery  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] Point in Time Recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Point in Time Recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
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)
>
>
>
>

pgsql-admin by date:

Previous
From: Si Chen
Date:
Subject: How to identify the transaction of a lock?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Point in Time Recovery