On Wed, Sep 27, 2023 at 3:37 PM vignesh C <vignes...@gmail.com> wrote: > > On Tue, 26 Sept 2023 at 10:58, vignesh C <vignes...@gmail.com> wrote: > > > > On Wed, 20 Sept 2023 at 16:54, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Fri, Sep 15, 2023 at 3:08 PM vignesh C <vignes...@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.
