Re: pg_upgrade and logical replication

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
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-13T10:32:27Z
Lists: pgsql-hackers
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.

>
>  However, if we have a failure after
> the transaction that created the slot commits, then we'd have an INIT
> relation in the catalog that got committed *and* a slot related to it
> lying around.
>

I don't think this can happen otherwise this could be a problem even
without an upgrade after restart.

-- 
With Regards,
Amit Kapila.



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