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 CAB7nPqQw2oeJgi457E+T+_piWsi1nnBLgmHO6T3LDBmhwZs6Yw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 4/25/17 21:47, Michael Paquier wrote:
>> Attached is an updated patch to reflect that.
>
> I edited this a bit, here is a new version.

Thanks, looks fine for me.

> A variant approach would be to prohibit *all* new commands after
> entering the "stopping" state, just let running commands run.  That way
> we don't have to pick which individual commands are at risk.  I'm not
> sure that we have covered everything here.

It seems to me that everything is covered. We are taking about
creation and dropping of slots here, where standby snapshots can be
created and SQL queries can be run when doing a tablesync meaning that
FPWs could be taken in the context of the WAL sender. Blocking all
commands would be surely safer I agree, but I see no reason to block
things more than necessary.
-- 
Michael



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] subscription worker doesn't start immediately on eabled
Next
From: Noah Misch
Date:
Subject: Re: [HACKERS] snapbuild woes