Horton

Re: pg_upgrade and logical replication[

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Peter Smith <smithpb2250@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-14T00:22:17Z
Lists: 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

Commits

  1. pg_upgrade: Retrieve subscription count more efficiently.

  2. Fix random failure in 004_subscription.

  3. Fix 004_subscription.pl to allow its usage in --link mode.

  4. Allow upgrades to preserve the full subscription's state.

  5. Prevent startup of logical replication launcher during pg_upgrade