On Mon, 10 Jun 2024 at 12:24, Amul Sul <sulamul@gmail.com> wrote: > > > > On Sat, Jun 8, 2024 at 6:43 PM vignesh C <vignesh21@gmail.com> wrote: >> >> On Wed, 5 Jun 2024 at 14:11, Amit Kapila <amit.kapila16@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.