From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | 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 07:11:40 |
Message-ID: | ced37900-2ab5-2c86-50db-0ca8c08c7eff@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/05/17 05:35, Michael Paquier wrote:
> 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.
>
I don't think the code covers all because a) the SQL queries are not
covered at all that I can see and b) logical decoding can theoretically
do HOT pruning (even if the chance is really small) so it's not safe to
start logical replication either.
I wonder if this whole prevent thing should just be called
unconditionally on walsender that's connected to database
(am_db_walsender), because in the WAL logging will only happen there -
CREATE_REPLICATION_SLOT PHYSICAL will not WAL log and
CREATE_REPLICATION_SLOT LOGICAL can't be run without being connected to
db, neither can logical decoding and SQL queries, so that coves all.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-05-02 07:17:27 | Re: Logical replication in the same cluster |
Previous Message | Petr Jelinek | 2017-05-02 06:55:53 | Re: snapbuild woes |