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: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Thu, 26 Feb 2026 00:02:56 -0800
Message-ID: <CAHg+QDfW8uwhO92sLaWzcyG2st8n+m99sRHwHPnrQo22fA5tyQ@mail.gmail.com>
Subject: Re: synchronized_standby_slots behavior inconsistent with
 quorum-based synchronous replication
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000108f4e064bb58dd2"
Archived-At: <https://www.postgresql.org/message-id/CAHg%2BQDfW8uwhO92sLaWzcyG2st8n%2Bm99sRHwHPnrQo22fA5tyQ%40mail.gmail.com>
Precedence: bulk

--000000000000108f4e064bb58dd2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Amit,

On Wed, Feb 25, 2026 at 10:20=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.c=
om>
wrote:

> ...
> >
> > 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?
>

+1, the job of failover orchestration is to ensure the new primary is
caught up at least until the quorum LSN. Otherwise, it can be a durability
issue where users see missing committed transactions.


> 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.
>

Thanks for sharing the links,  the approach is similar. DEFAULT to
SAME_AS_SYNCREP_STANDBYS  is an interesting option.
I like the idea of avoiding duplicate lists unless the user wants to
maintain a separate list.

Thanks,
Satya

--000000000000108f4e064bb58dd2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Amit,</div><br><div class=3D"gmail_quo=
te gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb=
 25, 2026 at 10:20=E2=80=AFPM Amit Kapila &lt;<a href=3D"mailto:amit.kapila=
16@gmail.com">amit.kapila16@gmail.com</a>&gt; wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
...<br>
&gt;<br>
&gt; Thinking about this further, using quorum settings for<br>
&gt; synchronized_standby_slots can/will certainly result in at least one<b=
r>
&gt; sync standby lagging behind the logical replica, making it probably<br=
>
&gt; impossible to continue with the existing logical replication setup<br>
&gt; after a failover to the standby that lags behind. Here is what I am<br=
>
&gt; mean:<br>
&gt;<br>
<br>
But won&#39;t that be true even for synchronous_standby_names? I think in<b=
r>
the case of quorum, it is the responsibility of the failover solution<br>
to select the most recent synced standby among all the standby&#39;s<br>
specified in synchronous_standby_names. Similarly here before failing<br>
over logical subscriber to one of physical standby, the failover tool<br>
needs to ensure it is switching over to the synced replica. We have<br>
given steps in the docs [1] that could be used to identify the replica<br>
where the subscriber can switchover. Will that address your concern?<br></b=
lockquote><div><br></div><div>+1, the job of failover orchestration is to e=
nsure the new primary is caught up at least until the quorum LSN. Otherwise=
, it can be a durability issue where users see missing committed transactio=
ns.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
BTW, I have also suggested this idea in thread [2]. I don&#39;t recall all<=
br>
the ideas/points discussed in that thread but it would be good to<br>
check that thread for any alternative ideas and points raised, so that<br>
we don&#39;t miss anything.<br></blockquote><div><br></div><div>Thanks for =
sharing the links,=C2=A0 the approach is=C2=A0similar. DEFAULT to SAME_AS_S=
YNCREP_STANDBYS=C2=A0 is an interesting option.=C2=A0</div><div>I like the =
idea of avoiding=C2=A0duplicate lists unless the user wants to maintain a s=
eparate list.<br></div><div><br></div><div>Thanks,</div><div>Satya</div></d=
iv></div>

--000000000000108f4e064bb58dd2--