On Mon, Oct 27, 2025 at 5:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Oct 27, 2025 at 12:19 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Mon, 27 Oct 2025 at 10:04, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >
> > >
> > > One question, I am not sure if this has been discussed before, So while getting sequence information from remote
weare also getting the page_lsn of the sequence and we are storing that in pg_subscription_rel. Is it just for the
userto see and compare whether the sequence is synced to the latest lsn or is it used for anything else as well? In
ourpatch sert, I don't see much usability information about this field.
> >
> > This is mainly intended for the following purposes: a) To determine
> > whether the sequence requires resynchronization by comparing it with
> > the latest LSN on the publisher b. ) To maintain consistency with
> > table synchronization behavior. c) To inform users up to which LSN
> > the sequence has been synchronized.
> > Further details will be documented in an upcoming patch.
> >
>
> Can we use it to build an auto-sequence-sync feature? One can imagine
> that at some threshold interval apply_worker can check if any of the
> replicated sequences are out-of-sync and if so, then sync those. We
> can do this before the apply_worker waits for some activity or on a
> clean shutdown.
>
We can even consider letting sequence sync worker do this by not
exiting it after syncing all required sequences. Having said that,
even if this is feasible, we should consider it as a top-up patch
after the sequence sync worker patch is committed.
--
With Regards,
Amit Kapila.
