On Wed, Sep 27, 2023 at 3:37 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Tue, 26 Sept 2023 at 10:58, vignesh C <vignesh21@gmail.com> wrote:
> >
> > 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.
>
> Once the table is in SUBREL_STATE_SYNCDONE state, the apply worker
> will check if the apply worker has some LSN records that need to be
> applied to reach the LSN of the table. Once the required WAL is
> applied, the table state will be changed from SUBREL_STATE_SYNCDONE to
> SUBREL_STATE_READY state. Since there is a chance that in this case
> the apply worker has to apply some transactions to get all the tables
> in READY state, I felt the minimum requirement should be that at least
> all the tables should be in READY state for the upgradation of the
> subscriber.
>
I don't think this theory is completely correct because the pending
WAL can be applied even after an upgrade.
--
With Regards,
Amit Kapila.
