On Tue, May 2, 2017 at 4:11 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:
> On 02/05/17 05:35, Michael Paquier wrote:
>> On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut
>> <peter.eisentraut@2ndquadrant.com> wrote:
>>> On 4/25/17 21:47, Michael Paquier wrote:
>>>> Attached is an updated patch to reflect that.
>>>
>>> I edited this a bit, here is a new version.
>>
>> Thanks, looks fine for me.
>>
>>> A variant approach would be to prohibit *all* new commands after
>>> entering the "stopping" state, just let running commands run. That way
>>> we don't have to pick which individual commands are at risk. I'm not
>>> sure that we have covered everything here.
>>
>> It seems to me that everything is covered. We are taking about
>> creation and dropping of slots here, where standby snapshots can be
>> created and SQL queries can be run when doing a tablesync meaning that
>> FPWs could be taken in the context of the WAL sender. Blocking all
>> commands would be surely safer I agree, but I see no reason to block
>> things more than necessary.
>>
>
> I don't think the code covers all because a) the SQL queries are not
> covered at all that I can see and b) logical decoding can theoretically
> do HOT pruning (even if the chance is really small) so it's not safe to
> start logical replication either.
Ahhh. So START_REPLICATION can also now generate WAL. Good to know.
--
Michael
