Re: PATCH: Make pg_stop_backup() archive wait optional

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: Make pg_stop_backup() archive wait optional
Date: 2017-02-28 00:50:37
Message-ID: CAB7nPqS-vH_Hk=+n63SHKS4ZrpknwNN9KMr9WkPZ9De=wU02Yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 28, 2017 at 9:42 AM, David Steele <david(at)pgmasters(dot)net> wrote:
> On 2/27/17 7:38 PM, Michael Paquier wrote:
>> On Tue, Feb 28, 2017 at 9:25 AM, David Steele <david(at)pgmasters(dot)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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2017-02-28 00:52:57 Re: PATCH: Make pg_stop_backup() archive wait optional
Previous Message Tomas Vondra 2017-02-28 00:44:42 Re: PATCH: two slab-like memory allocators