On Mon, Jun 10, 2024 at 5:00 PM vignesh C <vignes...@gmail.com> wrote: > > On Mon, 10 Jun 2024 at 12:24, Amul Sul <sula...@gmail.com> wrote: > > > > > > > > On Sat, Jun 8, 2024 at 6:43 PM vignesh C <vignes...@gmail.com> wrote: > >> > >> On Wed, 5 Jun 2024 at 14:11, Amit Kapila <amit.kapil...@gmail.com> wrote: > >> [...] > >> A new catalog table, pg_subscription_seq, has been introduced for > >> mapping subscriptions to sequences. Additionally, the sequence LSN > >> (Log Sequence Number) is stored, facilitating determination of > >> sequence changes occurring before or after the returned sequence > >> state. > > > > > > Can't it be done using pg_depend? It seems a bit excessive unless I'm > > missing > > something. > > We'll require the lsn because the sequence LSN informs the user that > it has been synchronized up to the LSN in pg_subscription_seq. Since > we are not supporting incremental sync, the user will be able to > identify if he should run refresh sequences or not by checking the lsn > of the pg_subscription_seq and the lsn of the sequence(using > pg_sequence_state added) in the publisher.
How the user will know from seq's lsn that he needs to run refresh. lsn indicates page_lsn and thus the sequence might advance on pub without changing lsn and thus lsn may look the same on subscriber even though a sequence-refresh is needed. Am I missing something here? thanks Shveta