Re: Updated backup APIs for non-exclusive backups

On Wed, Mar 30, 2016 at 10:09 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Tue, Mar 29, 2016 at 11:39 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
>
>> On Tue, Mar 29, 2016 at 6:40 PM, Magnus Hagander <magnus(at)hagander(dot)net>
>> wrote:
>>
>>> So - I can definitely see the argument for returning the stop wal
>>> *location*. But I'm still not sure what the definition of the time would
>>> be? We can't return it before we know what it means...
>>>
>>
>>
>> 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 exlcusive 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.
>>
>
> Currently pg_control has been read before backup_label file, so as per
> this proposal do you want to change that? If yes, I think that will make
> this patch more invasive with respect to handling of failure modes. Also
> as David points out, I also feel that it will raise the bar for usage of
> this API.
>

Yes, we'd have to change that. I don't think it's going to be much more
invasive than reading part of it from pg_control and part of it from
backup_label, as suggested by David. It would be a bit more complicated
than what we have today - but it would move complication from user scripts
(that are likely to get it wrong) to a central place in the backend (where
we can be more certain that it's at least less wrong).

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/