Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
Date
Msg-id CAB7nPqSXgd=VaxX5PBp17HvkKOoZ4NtZZf2_Y8QqykEY1WprvA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Fri, May 5, 2017 at 11:50 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 5/5/17 01:26, Michael Paquier wrote:
>> The only code path doing HOT-pruning and generating WAL is
>> heap_page_prune(). Do you think that we need to worry about FPWs as
>> well?
>>
>> Attached is an updated patch, which also forbids the run of any
>> replication commands when the stopping state is reached.
>
> I have committed this without the HOT pruning change.  That can be
> considered separately, and I think it could use another round of
> thinking about it.

Agreed. Just adding an ERROR message in XLogInsert() is not going to
help much as this leads also to PANIC for critical sections :(
So a patch really needs to be a no-op for all WAL-related operations
within the WAL sender, and that will be quite invasive I am afraid.

> I will move the open item to "Older Bugs" now, because the user
> experience regression, so to speak, in version 10 has been addressed.
> (This could be a backpatching candidate, but I am not planning on it for
> next week's releases in any case.)

No issues with all that.
-- 
Michael



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: [HACKERS] "CURRENT_ROLE" is not documented
Next
From: Vik Fearing
Date:
Subject: Re: [HACKERS] password_encryption, default and 'plain' support