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 CAB7nPqSjYR0nwKvH-4=MHDRkuQC1oCgODXhpHvmXpk+kQhkqtg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On Thu, Apr 20, 2017 at 12:40 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Apr 20, 2017 at 4:57 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> 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?

2nd thoughts here... Ah now I see your point. True that there is no
way to ensure that an unwanted command is not running when SIGUSR2 is
received as the shutdown checkpoint may have already begun. Here is an
idea: add a new state in WalSndState, say WALSNDSTATE_STOPPING, and
the shutdown checkpoint does not run as long as all WAL senders still
running do not reach such a state.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
Next
From: Vitaly Burovoy
Date:
Subject: Re: [HACKERS] identity columns