public inbox for [email protected]
help / color / mirror / Atom feedFrom: shveta malik <[email protected]>
To: Peter Smith <[email protected]>
Cc: Ajin Cherian <[email protected]>
Cc: Ashutosh Sharma <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: shveta malik <[email protected]>
Subject: Re: [PATCH] Support automatic sequence replication
Date: Thu, 19 Feb 2026 09:35:03 +0530
Message-ID: <CAJpy0uCi4DNz_NxqsFMY_u_Kfq8+o0J2gk0w0v6X3Mrf0MuL9A@mail.gmail.com> (raw)
In-Reply-To: <CAHut+Ptm-yvwJac3kVJRUhyapf=m-05Y1An8RAbvEWwMFUoE3Q@mail.gmail.com>
References: <CAFPTHDZXX9WQ_X1ZfEvS248T+pKuk6SmCnXcvgPM059N1xPUfA@mail.gmail.com>
<CAJpy0uDLUEjHHME8om1vAf6qkXCeRR6cBvkpK8yWBAC=T0ZFLA@mail.gmail.com>
<CAFPTHDZg1JrunGgOj332hr+gUuH_Jm7skqPpYSvd-QE3yEdRDQ@mail.gmail.com>
<CAJpy0uBz7MCSUkvFJD9ij65vBahNmY+bfCgdGKRqXovYs+K_TA@mail.gmail.com>
<CAJpy0uDsuNqjWd-TmGBxqSS1rnVCJ3B8=SYrtxQ=Vs8kb71QFA@mail.gmail.com>
<CAJpy0uAMWg3KcXtVBS7B0rnchLNrCCVYBByJCzAp=u5LERgtfA@mail.gmail.com>
<CAFPTHDZwEhxhDAeqcPi0GuYN6xBs8gFXHOMUnbg3u2Xigcz4Zg@mail.gmail.com>
<CAE9k0PmTyCU1A9YEf+MRgfeZ8yK1bAYJu=o0bH8DNUTzXejQyQ@mail.gmail.com>
<CAA4eK1L6czEzG4mLNZSyjYC5nX0FMSjjk3csKuxPD3Ph5-7Yvw@mail.gmail.com>
<CAJpy0uAhGQJ=msVsn2GsqWXr+YESJK6x9NBvrUtKvtvp1OVuKQ@mail.gmail.com>
<CAJpy0uAOuu-M6wobH2wHOdTymm-cX9+MqwPyRNoOt=sPKBdCew@mail.gmail.com>
<CAHut+Ptm-yvwJac3kVJRUhyapf=m-05Y1An8RAbvEWwMFUoE3Q@mail.gmail.com>
On Thu, Feb 19, 2026 at 3:26 AM Peter Smith <[email protected]> wrote:
>
> On Wed, Feb 18, 2026 at 9:05 PM shveta malik <[email protected]> wrote:
> >
> ...
> > 3)
> > I noticed that copy_sequences is invoked twice per sync cycle—once for
> > sequences in the INIT state, and once for sequences in the READY state
> > to detect drift. This means we ping the primary twice during each sync
> > cycle. We should consider combining this logic into a single
> > copy_sequences call. Since we already have the state information
> > (INIT, READY, etc.) for each local sequence, copy_sequences can
> > internally check the current state and decide whether to transition a
> > sequence to READY based on its previous state. This approach would
> > allow us to fetch all required information from the primary in a
> > single call.
> >
> > I also think that we do not even need to mention the states here and
> > we can give a single message instead of 2:
> > DEBUG: logical replication sequence synchronization for subscription
> > "sub1" - for sequences in INIT state batch #1 = 5 attempted, 5
> > succeeded, 0 mismatched, 0 insufficient permission, 0 missing from
> > publisher, 0 skipped, 0 no drift
> > DEBUG: logical replication sequence synchronization for subscription
> > "sub1" - for sequences in READY state batch #1 = 5 attempted, 0
> > succeeded, 0 mismatched, 0 insufficient permission, 0 missing from
> > publisher, 0 skipped, 5 no drift
> >
>
> Those are DEBUG1 messages, not LOG messages, so I think the primary
> goal is to ensure that they are full of useful information to help
> debugging. Knowing the prior state information means we know that the
> "drift" logic was needed when deciding to sync or not.
>
> If message volume can be reduced without any loss of debugging
> usefulness, then great, but we need to take care not to throw the baby
> out with the bath water.
>
> If message volume is a problem, then maybe that should be addressed by
> using more log levels DEBUG1,DEBUG2,DEBUG3,... etc.
>
I am not totally against it, but I don’t find it particularly useful
to dump the state (INIT, READY), since we already log exactly which
sequences were updated individually (see below). The output below
covers both cases—sequences with drift and those in the INIT state. We
also include the “no drift” count. So all of these effectively
summarizes the overall status.
logical replication sync for subscription "sub2", sequence
"public.myseq1" has been updated
logical replication sync for subscription "sub2", sequence
"public.myseq2" has been updated
Even if we plan to retain multiple messages for INIT vs READY, I
guess, with copy_sequences() now suggested to be called only once
irrespective of 'state' will make it further tricky to separate out
these log messages for INIT and READY. But let's see.
> I think it is useful to discuss how much DEBUG information is
> required. However, I would like to know if this is related to the
> patch being discussed or a case in HEAD? If later, then it is better
> to discuss it separately and address it as a separate patch if
> required.
Amit, this is related to the new patch only.
thanks
Shveta
view thread (58+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Support automatic sequence replication
In-Reply-To: <CAJpy0uCi4DNz_NxqsFMY_u_Kfq8+o0J2gk0w0v6X3Mrf0MuL9A@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox