| From: | vignesh C <vignesh21(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_upgrade and logical replication |
| Date: | 2023-09-26 05:28:12 |
| Message-ID: | CALDaNm3QgD17nNVmdPtTfP+J5F_UfGqC9n40c+X+RV9VAfWa-Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 20 Sept 2023 at 16:54, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Sep 15, 2023 at 3:08 PM vignesh C <vignesh21(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2023-09-26 05:41:51 | Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c) |
| Previous Message | NINGWEI CHEN | 2023-09-26 05:25:12 | Re: Remove MSVC scripts from the tree |