Re: pg_upgrade and logical replication[ - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_upgrade and logical replication[
Date
Msg-id ZVK9uePiX5Qsla-_@paquier.xyz
Whole thread Raw
In response to Re: pg_upgrade and logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pg_upgrade and logical replication[
List pgsql-hackers
On Mon, Nov 13, 2023 at 04:02:27PM +0530, Amit Kapila wrote:
> On Mon, Nov 13, 2023 at 1:52 PM Michael Paquier <michael@paquier.xyz> wrote:
>> It seems to me that INIT cannot be relied on for a similar reason.
>> This state would be set for a new relation in
>> LogicalRepSyncTableStart(), and the relation would still be in INIT
>> state when creating the slot via walrcv_create_slot() in a second
>> transaction started a bit later.
>
> Before creating a slot, we changed the state to DATASYNC.

Still, playing the devil's advocate, couldn't it be possible that a
server crashes just after the slot got created, then restarts with
max_logical_replication_workers=0?  This would keep the catalog in a
state authorized by the upgrade, still leak a replication slot on the
publication side if the node gets upgraded.  READY in the catalog
seems to be the only state where we are guaranteed that there is no
origin and no slot remaining around.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Next
From: Andres Freund
Date:
Subject: Re: pgsql: doc: fix wording describing the checkpoint_flush_after GUC