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-14T03:54:16Z
Lists: pgsql-hackers
On Tue, Nov 14, 2023 at 5:52 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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,
>

The state should be DATASYNC by that time and I don't think that is an
authorized state by upgrade.

-- 
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