Re: Recovery target 'immediate' - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Recovery target 'immediate'
Date
Msg-id CA+TgmoZ8n2jEnZSe=KFMEMKCNyQkGD13g7rWm0VJyuCRXnC=yg@mail.gmail.com
Whole thread Raw
In response to Re: Recovery target 'immediate'  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Recovery target 'immediate'
Re: Recovery target 'immediate'
List pgsql-hackers
On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Restore points are definitely the way to go here, this is what they
> were created for. Stopping at a labelled location has a defined
> meaning for the user, which is much better than just "stop anywhere
> convenient", which I found so frightening.
>
> It should be straightforward to create a restore point with the same
> name as used in pg_start_backup('text');
>
> pg_basebackup backups would need to use a unique key, which is harder
> to achieve. If we write a WAL record at backup start that would make
> the starting LSN unique, so we could then use that for the restore
> point name for that backup.
>
> If people want anything else they can request an additional restore
> point at the end of the backup.

I personally find this to be considerably more error-prone than
Heikki's suggestion.  On the occasions when I have had the dubious
pleasure of trying to do PITR recovery, it's quite easy to supply a
recovery target that never actually gets matched - and then you
accidentally recover all the way to the end of WAL.  This is not fun.
Having a bulletproof way to say "recover until you reach consistency
and then stop" is a much nicer API.  I don't think "stop as soon as
possible" is at all the same thing as "stop anywhere convenient".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: libpq COPY handling
Next
From: Tom Lane
Date:
Subject: Re: libpq COPY handling