| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: logical replication and PANIC during shutdown checkpoint in publisher |
| Date: | 2017-05-02 03:35:42 |
| Message-ID: | CAB7nPqQw2oeJgi457E+T+_piWsi1nnBLgmHO6T3LDBmhwZs6Yw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 2, 2017 at 7:07 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2017-05-02 03:55:23 | Re: snapbuild woes |
| Previous Message | Peter Eisentraut | 2017-05-02 02:53:15 | Re: subscription worker doesn't start immediately on eabled |