On Mon, Oct 27, 2025 at 5:10 PM Amit Kapila <[email protected]> wrote: > > 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: > > > > > > > > > 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. >
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.
