Re: logical replication and PANIC during shutdown checkpoint in publisher
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>, Fujii Masao <masao.fujii@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-04-25T18:17:09Z
Lists: pgsql-hackers
On 4/21/17 00:11, Michael Paquier wrote: > Hmm. I have been actually looking at this solution and I am having > doubts regarding its robustness. In short this would need to be > roughly a two-step process: > - In PostmasterStateMachine(), SIGUSR2 is sent to the checkpoint to > make it call ShutdownXLOG(). Prior doing that, a first signal should > be sent to all the WAL senders with > SignalSomeChildren(BACKEND_TYPE_WALSND). SIGUSR2 or SIGINT could be > used. > - At reception of this signal, all WAL senders switch to a stopping > state, refusing commands that can generate WAL. > - Checkpointer looks at the state of all WAL senders, looping with a > sleep call of a couple of ms, refusing to launch the shutdown > checkpoint as long as all WAL senders have not switched to the > stopping state. > - In reaper(), once checkpointer is confirmed as stopped, signal again > the WAL senders, and tell them to perform the last loop. Yeah that looks like a reasonable approach. I'm not sure why in your patch you process got_SIGUSR2 in WalSndErrorCleanup() instead of in the main loop. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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