MIME-Version: 1.0
References: <CAHg+QDfU7rOebrLDESPpHSgdiadKbpCOmBokcbmM6Gr+A5VobQ@mail.gmail.com>
 <CAE9k0PnP0cPuisVeXM+Bma7n6J+HYqhVO5LffosXuHSw7drEDQ@mail.gmail.com>
 <CAE9k0Pm_6+4zW-X9zgBHhyLa9dqNKLM=zzUnVeH+ikoh45iALw@mail.gmail.com> <CAA4eK1+CNnJ=p4yTXJKDYKLiJQttjCBdJsoioFVyt=JOxH6chA@mail.gmail.com>
In-Reply-To: <CAA4eK1+CNnJ=p4yTXJKDYKLiJQttjCBdJsoioFVyt=JOxH6chA@mail.gmail.com>
From: Ashutosh Sharma <ashu.coek88@gmail.com>
Date: Thu, 26 Feb 2026 13:12:06 +0530
Message-ID: <CAE9k0PkW9pAWofkygh8DpA_Yp_9hwbVhWt=EgVH4Guwgvqo0KQ@mail.gmail.com>
Subject: Re: synchronized_standby_slots behavior inconsistent with
 quorum-based synchronous replication
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAE9k0PkW9pAWofkygh8DpA_Yp_9hwbVhWt%3DEgVH4Guwgvqo0KQ%40mail.gmail.com>
Precedence: bulk

Hi Amit,

On Thu, Feb 26, 2026 at 11:50=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.c=
om> wrote:
>
> On Thu, Feb 26, 2026 at 10:28=E2=80=AFAM Ashutosh Sharma <ashu.coek88@gma=
il.com> wrote:
> >
> >
> > > >
> > > > Proposal:
> > > >
> > > > Make synchronized_standby_slots quorum aware i.e. extend the GUC to=
 accept an ANY M (slot1, slot2, ...) syntax similar to synchronous_standby_=
names, so StandbySlotsHaveCaughtup() can return true when M of N slots (whe=
re M <=3D N and M >=3D 1) have caught up. I still prefer two different GUCs=
 for this as the list of slots to be synchronized can still be different (f=
or example, DBA may want to ensure Geo standby to be sync before allowing t=
he logical decoding client to read the changes). I kept synchronized_standb=
y_slots  parse logic similar to  synchronous_standby_names  to keep things =
simple. The default behavior is also not changed for  synchronized_standby_=
slots.
> > > >
> ...
> >
> > Thinking about this further, using quorum settings for
> > synchronized_standby_slots can/will certainly result in at least one
> > sync standby lagging behind the logical replica, making it probably
> > impossible to continue with the existing logical replication setup
> > after a failover to the standby that lags behind. Here is what I am
> > mean:
> >
>
> But won't that be true even for synchronous_standby_names? I think in
> the case of quorum, it is the responsibility of the failover solution
> to select the most recent synced standby among all the standby's
> specified in synchronous_standby_names. Similarly here before failing
> over logical subscriber to one of physical standby, the failover tool
> needs to ensure it is switching over to the synced replica. We have
> given steps in the docs [1] that could be used to identify the replica
> where the subscriber can switchover. Will that address your concern?
>

Here's my understanding of this:

I don't think we should be comparing "synchronous_standby_names" with
"synchronized_standby_slots", even though they appear similar in
purpose. All values listed in synchronous_standby_names represent
synchronous standbys exclusively, whereas synchronized_standby_slots
can hold values for both synchronous and asynchronous standbys. In
other words, every server referenced by synchronous_standby_names is
of the same type, but that may not be the case with
synchronized_standby_slots.

If a GUC can hold values of different types (sync vs. async), does it
really make sense to use a qualifier like ANY 1 (val1, val2) when val1
and val2 are different in nature? For example, suppose val1 is a
synchronous standby and val2 is an asynchronous standby, and we
configure ANY 1 (val1, val2). It's possible for val2 to get ahead of
val1 in terms of replication progress, which in turn could mean the
logical replica is also ahead of val1. So if we were to fail over to
val1 (since it's the only synchronous standby), we will not be able to
use the existing logical replication setup.

Please correct me if I have misunderstood anything here.

--
With Regards,
Ashutosh Sharma.