public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Peter Smith <[email protected]>
Cc: shveta malik <[email protected]>
Cc: Ajin Cherian <[email protected]>
Cc: Ashutosh Sharma <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: [PATCH] Support automatic sequence replication
Date: Thu, 19 Feb 2026 07:52:26 +0530
Message-ID: <CAA4eK1LDv1UathrGzsxpm=fm3Us0jy_yY31kV_znSLXukqq2Og@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.
>
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.
--
With Regards,
Amit Kapila.
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: <CAA4eK1LDv1UathrGzsxpm=fm3Us0jy_yY31kV_znSLXukqq2Og@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