Horton

Re: pg_upgrade and logical replication

vignesh C <vignesh21@gmail.com>

View thread View on postgr.es
From: vignesh C <vignesh21@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-26T05:28:12Z
Lists: pgsql-hackers 
On Wed, 20 Sept 2023 at 16:54, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Sep 15, 2023 at 3:08 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > The attached v8 version patch has the changes for the same.
> >
>
> Is the check to ensure remote_lsn is valid correct in function
> check_for_subscription_state()? How about the case where the apply
> worker didn't receive any change but just marked the relation as
> 'ready'?

I agree that remote_lsn will not be valid in the case when all the
tables are in ready state and there are no changes to be sent by the
walsender to the worker. I was not sure if this check is required in
this case in the check_for_subscription_state function. I was thinking
that this check could be removed.
I'm also checking why the tables should only be in ready state, the
check that is there in the same function, can we support upgrades when
the tables are in syncdone state or not. I will post my analysis once
I have finished checking on the same.

Regards,
Vignesh

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