On Thu, Apr 20, 2017 at 4:57 AM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 4/19/17 01:45, Michael Paquier wrote: >> On Tue, Apr 18, 2017 at 3:27 AM, Peter Eisentraut >> <peter.eisentr...@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 treated. An idea with the >> attached... > > I think the problem with a signal-based solution is that there is no > feedback. Ideally, you would wait for all walsenders to acknowledge the > receipt of SIGUSR2 (or similar) and only then proceed with the shutdown > checkpoint.
Are you sure that it is necessary to go to such extent? Why wouldn't it be enough to prevent any replication commands generating WAL to run when the WAL sender knows that the postmaster is in shutdown mode? -- Michael VMware vCenter Server www.vmware.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
