Re: Updated backup APIs for non-exclusive backups - Mailing list pgsql-hackers

From David Steele
Subject Re: Updated backup APIs for non-exclusive backups
Date
Msg-id 56FB35A3.2000009@pgmasters.net
Whole thread Raw
In response to Re: Updated backup APIs for non-exclusive backups  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Updated backup APIs for non-exclusive backups
List pgsql-hackers
On 3/29/16 2:09 PM, Magnus Hagander wrote:

> I had a chat with Heikki, and here's another suggestion:
> 
> 1. We don't touch the current exclusive backups at all, as previously
> discussed, other than deprecating their use. For backwards compat.
> 
> 2. For new backups, we return the contents of pg_control as a bytea from
> pg_stop_backup(). We tell backup programs they are supposed to write
> this out as pg_control.backup, *not* as pg_control.
> 
> 3a. On recovery, if it's an exclusive backup, we do as we did before.
> 
> 3b. on recovery, in non-exclusive backups (determined from
> backup_label), we check that pg_control.backup exists *and* that
> pg_control does *not* exist. That guards us reasonably against backup
> programs that do the wrong thing, and we know we get the correct version
> of pg_control.
> 
> 4. (we can still add the stop location to the backup_label file in case
> backup programs find it useful, but we don't use it in recovery)
> 
> Thoughts about this approach?

This certainly looks like it would work but it raises the barrier for
implementing backups by quite a lot.  It's fine for backrest or barman
but it won't be pleasant for anyone who has home-grown scripts.

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Please correct/improve wiki page about abbreviated keys bug
Next
From: Dilip Kumar
Date:
Subject: Re: Relation extension scalability