From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Updated backup APIs for non-exclusive backups |
Date: | 2016-03-30 02:10:43 |
Message-ID: | 56FB35A3.2000009@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2016-03-30 02:21:30 | Re: Relation extension scalability |
Previous Message | Peter Geoghegan | 2016-03-30 02:03:29 | Re: Please correct/improve wiki page about abbreviated keys bug |