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
-
Expose waitforarchive option through pg_stop_backup()
- 017e4f2588a7 10.0 landed
-
Mark pg_start_backup and pg_stop_backup as parallel-restricted.
- 9fe3c644a731 10.0 landed