Re: logical replication and PANIC during shutdown checkpoint in publisher
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>,
Petr Jelinek <petr.jelinek@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-04-19T05:45:36Z
Lists: pgsql-hackers
Attachments
- walsender-shutdown-fix.patch (application/octet-stream) patch
On Tue, Apr 18, 2017 at 3:27 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > I'd imagine the postmaster would tell the walsender that it has started > shutdown, and then the walsender would reject $certain_things. But I > don't see an existing way for the walsender to know that shutdown has > been initiated. SIGINT is still free ... The WAL sender receives SIGUSR2 from the postmaster when shutdown is initiated, so why not just rely on that and issue an ERROR when a client attempts to create or drop a new slot, setting up walsender_ready_to_stop unconditionally? It seems to me that the issue here is the delay between the moment SIGTERM is acknowledged by the WAL sender and the moment CREATE_SLOT is treater. An idea with the attached... > The alternative of shutting down logical walsenders earlier also doesn't > look straightforward, since the postmaster doesn't know directly what > kind of walsender a certain process is. So you'd also need additional > signal types or something there. Yup, but is a switchover between a publisher and a subscriber something that can happen? -- Michael
Commits
-
Prevent possibility of panics during shutdown checkpoint.
- 862204aaceb1 9.6.4 landed
- 50581f2e74fa 9.5.8 landed
- 1cdc0ab9c180 9.4.13 landed
- c6c333436491 10.0 landed
-
Revert "Prevent panic during shutdown checkpoint"
- 703f148e98ec 10.0 landed
-
Prevent panic during shutdown checkpoint
- 086221cf6b17 10.0 cited