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. Regards, Vignesh
