Re: logical replication and PANIC during shutdown checkpoint in publisher

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-06-01T22:05:18Z
Lists: pgsql-hackers
On 2017-05-05 10:50:11 -0400, Peter Eisentraut 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.

I'm a unhappy how this is reusing SIGINT for WalSndLastCycleHandler.
Normally INT is used cancel interrupts, and since walsender is now also
working as a normal backend, this overlap is bad.  Even for plain
walsender backend this seems bad, because now non-superusers replication
users will terminate replication connections when they do
pg_cancel_backend().  For replication=dbname users it's especially bad
because there can be completely legitimate uses of pg_cancel_backend().

- Andres


Commits

  1. Prevent possibility of panics during shutdown checkpoint.

  2. Revert "Prevent panic during shutdown checkpoint"

  3. Prevent panic during shutdown checkpoint