Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional
От | David Steele |
---|---|
Тема | Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional |
Дата | |
Msg-id | 967b90bd-6b65-a18a-5266-bfa9191c40e6@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional
|
Список | 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
В списке pgsql-hackers по дате отправления: