Re: PATCH: Make pg_stop_backup() archive wait optional

David Steele <david@pgmasters.net>

From: David Steele <david@pgmasters.net>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-28T00:52:57Z
Lists: pgsql-hackers
On 2/27/17 7:50 PM, Michael Paquier wrote:
> On Tue, Feb 28, 2017 at 9:42 AM, David Steele <david@pgmasters.net> wrote:
>> On 2/27/17 7:38 PM, Michael Paquier wrote:
>>> On Tue, Feb 28, 2017 at 9:25 AM, David Steele <david@pgmasters.net> wrote:
>>>> I also marked the pg_stop_* functions as parallel restricted, the same
>>>> as pg_start_backup().  Previously they were parallel safe which I don't
>>>> believe is accurate for the non-exclusive version at the very least,
>>>> since it is tied to a particular backend.
>>>
>>> Yeah, those should really be parallel restricted. For the exclusive
>>> version, having the function run in parallel would also lead to errors
>>> per the presence/lack of backup_label file.
>>
>> I'm not sure that's the case.  It seems like it should lock just as
>> multiple backends would now.  One process would succeed and the others
>> would error.  Maybe I'm missing something?
> 
> Hm, any errors happening in the workers would be reported to the
> leader, meaning that even if one worker succeeded to run
> pg_start_backup() it would be reported as an error at the end to the
> client, no? By marking the exclusive function restricted we get sure
> that it is just the leader that fails or succeeds.

Good point, and it strengthens the argument beyond, "it just seems right."

-- 
-David
david@pgmasters.net


Commits

  1. Expose waitforarchive option through pg_stop_backup()

  2. Mark pg_start_backup and pg_stop_backup as parallel-restricted.