MIME-Version: 1.0
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>
In-Reply-To: <CAJpy0uAOuu-M6wobH2wHOdTymm-cX9+MqwPyRNoOt=sPKBdCew@mail.gmail.com>
From: Peter Smith <smithpb2250@gmail.com>
Date: Thu, 19 Feb 2026 08:56:29 +1100
Message-ID: <CAHut+Ptm-yvwJac3kVJRUhyapf=m-05Y1An8RAbvEWwMFUoE3Q@mail.gmail.com>
Subject: Re: [PATCH] Support automatic sequence replication
To: shveta malik <shveta.malik@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAHut%2BPtm-yvwJac3kVJRUhyapf%3Dm-05Y1An8RAbvEWwMFUoE3Q%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 18, 2026 at 9:05=E2=80=AFPM shveta malik <shveta.malik@gmail.co=
m> wrote:
>
...
> 3)
> I noticed that copy_sequences is invoked twice per sync cycle=E2=80=94onc=
e 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 =3D 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 =3D 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.

=3D=3D=3D=3D=3D=3D
Kind Regards,
Peter Smith.
Fujitsu Australia