|From:||David Steele <david(at)pgmasters(dot)net>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: PATCH: Make pg_stop_backup() archive wait optional|
|Views:||Raw Message | Whole Thread | Download mbox|
On 3/4/17 1:58 AM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 9:07 AM, David Steele <david(at)pgmasters(dot)net> wrote:
>> On 2/28/17 10:22 PM, Robert Haas wrote:
>>> On Tue, Feb 28, 2017 at 6:22 AM, David Steele <david(at)pgmasters(dot)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
>> 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.
> 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.
|Next Message||Andrew Dunstan||2017-03-04 14:20:23||Re: check failure with -DRELCACHE_FORCE_RELEASE -DCLOBBER_FREED_MEMORY|
|Previous Message||Stephen Frost||2017-03-04 14:00:04||Re: Cost model for parallel CREATE INDEX|