On Mon, Oct 27, 2025 at 12:19 PM vignesh C <[email protected]> wrote: > > On Mon, 27 Oct 2025 at 10:04, Dilip Kumar <[email protected]> wrote: > > > > On Mon, Oct 27, 2025 at 8:23 AM Zhijie Hou (Fujitsu) > > <[email protected]> wrote: > >> > >> On Friday, October 24, 2025 11:22 PM vignesh C <[email protected]> wrote: > >> > > >> > On Thu, 23 Oct 2025 at 16:47, Amit Kapila <[email protected]> > >> > wrote: > >> > > > >> > > On Thu, Oct 23, 2025 at 11:45 AM vignesh C <[email protected]> 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 are also getting the page_lsn > > of the sequence and we are storing that in pg_subscription_rel. Is it just > > for the user to see and compare whether the sequence is synced to the > > latest lsn or is it used for anything else as well? In our patch 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. That way users won't need to manually sync these sequences before upgrade. -- With Regards, Amit Kapila.
