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. Also, this parallels our > implementation for pg_subscription_seq and will aid in expanding for > a) incremental synchronization and b) utilizing workers for > synchronization using sequence states if necessary. > > How do you track sequence mapping with the publication? > > In the publisher we use pg_publication_rel and > pg_publication_namespace for mapping the sequences with the > publication. > Thanks for the explanation. I'm wondering what the complexity would be, if we wanted to do something similar on the subscriber side, i.e., tracking via pg_subscription_rel. Regards, Amul
