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>
In-Reply-To: <CAE9k0Pm_6+4zW-X9zgBHhyLa9dqNKLM=zzUnVeH+ikoh45iALw@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Thu, 26 Feb 2026 11:49:53 +0530
Message-ID: <CAA4eK1+CNnJ=p4yTXJKDYKLiJQttjCBdJsoioFVyt=JOxH6chA@mail.gmail.com>
Subject: Re: synchronized_standby_slots behavior inconsistent with
 quorum-based synchronous replication
To: Ashutosh Sharma <ashu.coek88@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/CAA4eK1%2BCNnJ%3Dp4yTXJKDYKLiJQttjCBdJsoioFVyt%3DJOxH6chA%40mail.gmail.com>
Precedence: bulk

On Thu, Feb 26, 2026 at 10:28=E2=80=AFAM Ashutosh Sharma <ashu.coek88@gmail=
.com> wrote:
>
>
> > >
> > > Proposal:
> > >
> > > Make synchronized_standby_slots quorum aware i.e. extend the GUC to a=
ccept an ANY M (slot1, slot2, ...) syntax similar to synchronous_standby_na=
mes, so StandbySlotsHaveCaughtup() can return true when M of N slots (where=
 M <=3D N and M >=3D 1) have caught up. I still prefer two different GUCs f=
or this as the list of slots to be synchronized can still be different (for=
 example, DBA may want to ensure Geo standby to be sync before allowing the=
 logical decoding client to read the changes). I kept synchronized_standby_=
slots  parse logic similar to  synchronous_standby_names  to keep things si=
mple. The default behavior is also not changed for  synchronized_standby_sl=
ots.
> > >
...
>
> 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?

BTW, I have also suggested this idea in thread [2]. I don't recall all
the ideas/points discussed in that thread but it would be good to
check that thread for any alternative ideas and points raised, so that
we don't miss anything.

[1] - https://www.postgresql.org/docs/current/logical-replication-failover.=
html
[2] - https://www.postgresql.org/message-id/CAA4eK1KLFdmj8CLrZNL0D4phqyQihb=
7NXOjmqvrU5DT8moQn9Q%40mail.gmail.com

--=20
With Regards,
Amit Kapila.