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:
> >
> > On Mon, Oct 27, 2025 at 8:23 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
> >>
> >> On Friday, October 24, 2025 11:22 PM vignesh C <vignesh21@gmail.com> wrote:
> >> >
> >> > On Thu, 23 Oct 2025 at 16:47, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> > >
> >> > > On Thu, Oct 23, 2025 at 11:45 AM vignesh C <vignesh21@gmail.com> wrote:
> >> > > >
> >> > > > The attached patch has the changes for the same.
> >> > > >
> >> > >
> >> > > I have pushed 0001 and the following are comments on 0002.
> >> >
> >
> >
> > One question, I am not sure if this has been discussed before, So while getting sequence information from remote we
arealso getting the page_lsn of the sequence and we are storing that in pg_subscription_rel. Is it just for the user
tosee and compare whether the sequence is synced to the latest lsn or is it used for anything else as well? In our
patchsert, 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. That way users won't need to manually sync these
sequences before upgrade.
--
With Regards,
Amit Kapila.
