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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
