Hi Robert,
On 3/4/17 1:58 AM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 9:07 AM, David Steele <david@pgmasters.net> wrote:
>> On 2/28/17 10:22 PM, Robert Haas wrote:
>>> On Tue, Feb 28, 2017 at 6:22 AM, David Steele <david@pgmasters.net> wrote:
>>>>>> 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."
>>>
>>> I think the argument should be based on whether or not the function
>>> depends on backend-private state that will not be synchronized.
>>> That's the definition of what makes something parallel-restricted or
>>> not.
>>
>> Absolutely. Yesterday was a long day so I may have (perhaps) become a
>> bit flippant.
>>
>>> It looks like pg_start_backup() and pg_stop_backup() depend on the
>>> backend-private global variable nonexclusive_backup_running, so they
>>> should be parallel-restricted.
>>
>> Agreed.
>
> How about a separately-committable patch that just does that, and then
> a main patch that applies on top of it?
Yes, that makes sense. Attached are two patches as requested:
01 - Just marks pg_stop_backup() variants as parallel restricted
02 - Add the wait_for_archive param to pg_stop_backup().
These apply cleanly on 272adf4.
Thanks,
--
-David
david@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
