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>
 <CAE9k0PkW9pAWofkygh8DpA_Yp_9hwbVhWt=EgVH4Guwgvqo0KQ@mail.gmail.com>
 <CAHg+QDeQ6MLTR7E3RSwwoEXon4z4uo_9P_oum1aGANbi1Go8Qg@mail.gmail.com>
 <CAJpy0uAMFqLjKMD4h3uuXBGXpGzeUBFQe80RJ9b26YQ3CXZbog@mail.gmail.com> <CAE9k0PnOUth5tjT21wD75QRUsREQ35=z9JgqOFVUdCLrQ62s3g@mail.gmail.com>
In-Reply-To: <CAE9k0PnOUth5tjT21wD75QRUsREQ35=z9JgqOFVUdCLrQ62s3g@mail.gmail.com>
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Thu, 26 Feb 2026 02:46:08 -0800
Message-ID: <CAHg+QDct_WLz8b+JpxvBYVUptEMySME4HR6NOodc1uCK91525g@mail.gmail.com>
Subject: Re: synchronized_standby_slots behavior inconsistent with
 quorum-based synchronous replication
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: shveta malik <shveta.malik@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000af6d6a064bb7d4c0"
Archived-At: <https://www.postgresql.org/message-id/CAHg%2BQDct_WLz8b%2BJpxvBYVUptEMySME4HR6NOodc1uCK91525g%40mail.gmail.com>
Precedence: bulk

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

Hi Ashutosh,

On Thu, Feb 26, 2026 at 1:11=E2=80=AFAM Ashutosh Sharma <ashu.coek88@gmail.=
com>
wrote:

> Hi,
>
> On Thu, Feb 26, 2026 at 2:15=E2=80=AFPM shveta malik <shveta.malik@gmail.=
com>
> wrote:
> >
> > On Thu, Feb 26, 2026 at 1:54=E2=80=AFPM SATYANARAYANA NARLAPURAM
> > <satyanarlapuram@gmail.com> wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > On Wed, Feb 25, 2026 at 11:42=E2=80=AFPM Ashutosh Sharma <
> ashu.coek88@gmail.com> wrote:
> > >>
> > >>
> > >> I don't think we should be comparing "synchronous_standby_names" wit=
h
> > >> "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 i=
t
> > >> really make sense to use a qualifier like ANY 1 (val1, val2) when va=
l1
> > >> 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.
> > >
> > >
> > > If the failover orchestrator cannot ensure standby1 to not get the
> quorum committed WAL (from archive or standby2) then the setting ANY 1
> (val1, val2) is invalid.
> > > This setup also has issues because in your scenario, standby2 is ahea=
d
> of the new primary (standby1) and standby2 requires now to rewind to be i=
n
> sync with the new primary. Additionally, it allowed readers to read data
> that was lost at the end of the failover. We ideally need a mechanism to
> not send WAL to async replicas before the sync replicas commit  (honoring
> syncrhnous_standby_names GUC) feature (similar to
> synchronized_standby_slots). It could be a different thread on its own.
> >
> >
> > +1 on the overall idea of the patch.
> > I understand the concern raised above that one of the standbys in the
> > quorum (synchronized_standby_slots) might lag behind the logical
> > replica, and a user could potentially failover to such a standby. But
> > I also agree with Amit that configuring failover correctly is
> > ultimately the responsibility of failover-solution. And instructions
> > in doc should be followed before deciding if a standby is
> > failover-ready or not.
> >
> > As suggested in [1], IMO, it is a reasonably good idea for
> > 'synchronized_standby_slots' to DEFAULT to the value of
> > 'synchronous_standby_names'. That way, even if the user missed to
> > configure 'synchronized_standby_slots' explicitly, we would still have
> > reasonable protection in place. At the same time, if a user
> > intentionally chooses not to configure it, a NULL/NONE value should
> > remain a valid option.
> >
>
> AFAIU, not all names listed in "synchronous_standby_names" are
> necessarily synchronous standbys. Tools like pg_receivewal, for
> example, can establish a replication connection to the primary and
> appear in that list. Therefore, deriving "synchronized_standby_slots"
> from "synchronous_standby_names", if not set by the user would cause
> logical slots to be synchronized to whatever nodes those names
> represent, including a host running pg_receivewal, which is certainly
> not something the user would have intended to do. Therefore I feel
> this might not just be the good choice.


Agreed, not a good idea to have  synchronized_standby_slots default to
synchronous_standby_names because application_names and slot names are
different as stated.

Thanks,
Satya

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ashutosh,</div><br><div class=3D"gmail=
_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu,=
 Feb 26, 2026 at 1:11=E2=80=AFAM Ashutosh Sharma &lt;<a href=3D"mailto:ashu=
.coek88@gmail.com">ashu.coek88@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Thu, Feb 26, 2026 at 2:15=E2=80=AFPM shveta malik &lt;<a href=3D"mailto:=
shveta.malik@gmail.com" target=3D"_blank">shveta.malik@gmail.com</a>&gt; wr=
ote:<br>
&gt;<br>
&gt; On Thu, Feb 26, 2026 at 1:54=E2=80=AFPM SATYANARAYANA NARLAPURAM<br>
&gt; &lt;<a href=3D"mailto:satyanarlapuram@gmail.com" target=3D"_blank">sat=
yanarlapuram@gmail.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; Hi Ashutosh,<br>
&gt; &gt;<br>
&gt; &gt; On Wed, Feb 25, 2026 at 11:42=E2=80=AFPM Ashutosh Sharma &lt;<a h=
ref=3D"mailto:ashu.coek88@gmail.com" target=3D"_blank">ashu.coek88@gmail.co=
m</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I don&#39;t think we should be comparing &quot;synchronous_st=
andby_names&quot; with<br>
&gt; &gt;&gt; &quot;synchronized_standby_slots&quot;, even though they appe=
ar similar in<br>
&gt; &gt;&gt; purpose. All values listed in synchronous_standby_names repre=
sent<br>
&gt; &gt;&gt; synchronous standbys exclusively, whereas synchronized_standb=
y_slots<br>
&gt; &gt;&gt; can hold values for both synchronous and asynchronous standby=
s. In<br>
&gt; &gt;&gt; other words, every server referenced by synchronous_standby_n=
ames is<br>
&gt; &gt;&gt; of the same type, but that may not be the case with<br>
&gt; &gt;&gt; synchronized_standby_slots.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; If a GUC can hold values of different types (sync vs. async),=
 does it<br>
&gt; &gt;&gt; really make sense to use a qualifier like ANY 1 (val1, val2) =
when val1<br>
&gt; &gt;&gt; and val2 are different in nature? For example, suppose val1 i=
s a<br>
&gt; &gt;&gt; synchronous standby and val2 is an asynchronous standby, and =
we<br>
&gt; &gt;&gt; configure ANY 1 (val1, val2). It&#39;s possible for val2 to g=
et ahead of<br>
&gt; &gt;&gt; val1 in terms of replication progress, which in turn could me=
an the<br>
&gt; &gt;&gt; logical replica is also ahead of val1. So if we were to fail =
over to<br>
&gt; &gt;&gt; val1 (since it&#39;s the only synchronous standby), we will n=
ot be able to<br>
&gt; &gt;&gt; use the existing logical replication setup.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; If the failover orchestrator cannot ensure standby1 to not get th=
e quorum committed WAL (from archive or standby2) then the setting ANY 1 (v=
al1, val2) is invalid.<br>
&gt; &gt; This setup also has issues because in your scenario, standby2 is =
ahead of the new primary (standby1) and standby2 requires now to rewind to =
be in sync with the new primary. Additionally, it allowed readers to read d=
ata that was lost at the end of the failover. We ideally need a mechanism t=
o not send WAL to async replicas before the sync replicas commit=C2=A0 (hon=
oring syncrhnous_standby_names GUC) feature (similar to synchronized_standb=
y_slots). It could be a different thread on its own.<br>
&gt;<br>
&gt;<br>
&gt; +1 on the overall idea of the patch.<br>
&gt; I understand the concern raised above that one of the standbys in the<=
br>
&gt; quorum (synchronized_standby_slots) might lag behind the logical<br>
&gt; replica, and a user could potentially failover to such a standby. But<=
br>
&gt; I also agree with Amit that configuring failover correctly is<br>
&gt; ultimately the responsibility of failover-solution. And instructions<b=
r>
&gt; in doc should be followed before deciding if a standby is<br>
&gt; failover-ready or not.<br>
&gt;<br>
&gt; As suggested in [1], IMO, it is a reasonably good idea for<br>
&gt; &#39;synchronized_standby_slots&#39; to DEFAULT to the value of<br>
&gt; &#39;synchronous_standby_names&#39;. That way, even if the user missed=
 to<br>
&gt; configure &#39;synchronized_standby_slots&#39; explicitly, we would st=
ill have<br>
&gt; reasonable protection in place. At the same time, if a user<br>
&gt; intentionally chooses not to configure it, a NULL/NONE value should<br=
>
&gt; remain a valid option.<br>
&gt;<br>
<br>
AFAIU, not all names listed in &quot;synchronous_standby_names&quot; are<br=
>
necessarily synchronous standbys. Tools like pg_receivewal, for<br>
example, can establish a replication connection to the primary and<br>
appear in that list. Therefore, deriving &quot;synchronized_standby_slots&q=
uot;<br>
from &quot;synchronous_standby_names&quot;, if not set by the user would ca=
use<br>
logical slots to be synchronized to whatever nodes those names<br>
represent, including a host running pg_receivewal, which is certainly<br>
not something the user would have intended to do. Therefore I feel<br>
this might not just be the good choice.</blockquote><div><br></div><div>Agr=
eed, not a good idea to have=C2=A0 synchronized_standby_slots default to sy=
nchronous_standby_names because application_names and slot names are differ=
ent as stated.</div><div><br></div><div>Thanks,</div><div>Satya=C2=A0</div>=
</div></div>

--000000000000af6d6a064bb7d4c0--