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>
 <CAHg+QDct_WLz8b+JpxvBYVUptEMySME4HR6NOodc1uCK91525g@mail.gmail.com>
 <CAE9k0P=NS0=epVh5XHMG3GmbMxf8Ff9R4wnYAsPLEjWzkVPcqw@mail.gmail.com>
 <CAFPTHDbrJJtaR4Jf2HNOZQVyBLJF-kq8kk=FvmeZ1rfU+Y3R5g@mail.gmail.com>
 <CAE9k0P=nsRZ4QSncmDzrpN19Pv1KUVRzmvSQj1=qzSF3KOaVnw@mail.gmail.com>
 <CAJpy0uC6=oeg=K0GGYv3WQcyeMdyREPDq02iUmh=-0iKDkR0Tg@mail.gmail.com>
 <CAE9k0P=LBJtCVayuggs9Za_iRpjoN=7aV9ptUwr3iO5ts5x8Wg@mail.gmail.com>
 <CAJpy0uAbj3FPTjATm6ReDRgRseQHkhKtDW+hy4Z9biXm5NPrsw@mail.gmail.com>
 <CAE9k0PnA25VEKFQamjkg+YwuSUyH6pF+Bb1jyoKX=pZx8Enppw@mail.gmail.com>
 <CAJpy0uDQH-bHuZpew7z0-oQkBZ76aXN6Zr2=23b10vtRAEjMMw@mail.gmail.com>
 <CAE9k0PkhdZCXrpCPRdezb0-Y_iUMgHWfUCBzNJR5reV8XaoRDg@mail.gmail.com>
 <CAJpy0uBz_qjHN4dvghTmVW18t+iYdw7NwSFnGT5C+kJaRZzrog@mail.gmail.com>
 <CAE9k0P=fo=EoJGYDr6eXnEKXpxs_eae0RSX=0kyHe6rMumsy1Q@mail.gmail.com>
 <CAJpy0uDFzdKH3ADpBKjeM-s-vPTqqd4mTnBJC3JXZHNPnsv5mg@mail.gmail.com>
 <CAE9k0PnfF27vzVnHoCxTZwbBH4yR1OMCw2MDdWc8k+bGd5sR0g@mail.gmail.com>
 <TY4PR01MB16907E4E69204C3B318866AF8944FA@TY4PR01MB16907.jpnprd01.prod.outlook.com>
 <CAJpy0uCZ3OsextxRhBk8aWTua3v==Vc9QRP7fwO6qd=MTXMyPg@mail.gmail.com>
 <CAE9k0Pm-qakqxs7xGZFisNz3i_3S7C5N=wtFzZGxCMvcnB+cYg@mail.gmail.com>
 <TY4PR01MB16907E62E50E88C44F5747ABD944CA@TY4PR01MB16907.jpnprd01.prod.outlook.com>
 <CAE9k0PnMQkHbWho+pnBBLkeS0s4V3J4TjGbjy_tk-Q__poc7rQ@mail.gmail.com>
 <CAA4eK1JvsBwezSPnnVGC6NL2umkZjTANxvM8rh8OWxFVN_DfPg@mail.gmail.com>
 <CAE9k0PmfHRT25TG1MqWNhvppyA+_grSAnwxffq7LsV0NV6ik6Q@mail.gmail.com>
 <CAE9k0P=WsXS6xbtzgf9kT+BvwrqYo0JfzbUM2hvYP7MRrUxxwA@mail.gmail.com>
 <CAA4eK1JFxJPHLaT3Lmk+rEv3aEOZeBz2HCWbe2cmAPhJUA-rvQ@mail.gmail.com>
 <CAE9k0Pn_FpewF+88eh2BCzzVxdAhEn+GcdYwwVCqpw_SbEuCyw@mail.gmail.com>
 <CAJpy0uDBxMUznWmqfoDUkg9=FDhiGJaQi3mHKHTd3-HZBKmx2A@mail.gmail.com>
 <CAE9k0Pn+c1rdzemtCt8eR6BwNJBubU9uR6R92BXK9yU7MLwEbg@mail.gmail.com>
 <CAJpy0uCGw_3OXFqO6OHAKRPei_xkogaVJBHfvS-RQppxMAGdMg@mail.gmail.com>
 <CAE9k0Pn1Xr37KDCViQLybd-K8rcY073XgQjKL_H4Ai4AE=POjQ@mail.gmail.com>
 <CAJpy0uCKGCkfCXCd=tsDH5e85x155LsdbZW46WpWfsZJUe82bw@mail.gmail.com>
 <CAJpy0uDQysu1mcLfCm44sfXGxqMBp8mdit979CQ25ObBWUZhrQ@mail.gmail.com>
 <CAE9k0P=GC51G2g_odG_pvp2Tbg9Ks=tNHwvAZQuQpb0na2JmkA@mail.gmail.com>
In-Reply-To: 
 <CAE9k0P=GC51G2g_odG_pvp2Tbg9Ks=tNHwvAZQuQpb0na2JmkA@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Thu, 4 Jun 2026 09:13:52 +0530
Message-ID: 
 <CAJpy0uBT8JbEGE0xvm-Wxh1g_VVgC=whKqChZo-uB+VOa_YCTw@mail.gmail.com>
Subject: Re: synchronized_standby_slots behavior inconsistent with
 quorum-based synchronous replication
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	=?UTF-8?B?SG91LCBaaGlqaWUv5L6vIOW/l+adsA==?= <houzj.fnst@fujitsu.com>,
	Ajin Cherian <itsajin@gmail.com>,
 SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 shveta malik <shveta.malik@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJpy0uBT8JbEGE0xvm-Wxh1g_VVgC%3DwhKqChZo-uB%2BVOa_YCTw%40mail.gmail.com>
Precedence: bulk

On Wed, Jun 3, 2026 at 4:30=E2=80=AFPM Ashutosh Sharma <ashu.coek88@gmail.c=
om> wrote:
>
> Hi Shveta,
>
> On Fri, May 15, 2026 at 9:28=E2=80=AFAM shveta malik <shveta.malik@gmail.=
com> wrote:
> >
> >
> > Ashutosh, while testing further, I noticed that
> > 'synchronized_standby_slots' does not filter duplicate entries. As an
> > example, if user ends up giving one entry twice in priority
> > configuration, then we will end up waiting on one slot twice rather
> > than waiting on 2 different slots.
> >
> > Example:
> > alter system set synchronized_standby_slots =3D 'FIRST 2 (standby_1,
> > standby_1, standby_2, standby_3)';
> > select pg_reload_conf();
> > insert into tab1 values (10), (20), (30);
> > select pg_logical_slot_get_binary_changes('sub1', NULL, NULL,
> > 'proto_version', '4', 'publication_names', 'pub1');
> >
> > The last statement works even though standby_2 and standby_3 do not
> > exist. It consumes standby_1 twice and thinks that the required number
> > of slots has caught-up.
> >
> > OTOH, if we use the same configuration for
> > 'synchronous_standby_names', it correctly waits for standby_2 and does
> > not count on standby_1 twice.
> >
> > alter system set synchronous_standby_names =3D 'FIRST 2 (standby_1,
> > standby_1, standby_2, standby_3)';
> > insert into tab1 values (10), (20), (30);  ----> This will wait on stan=
dby_2
> >
> > This is perhaps because 'synchronous_standby_names ' waits on active
> > WAL senders rather than repeated strings in configuration. But our
> > code changes wait on the names present in 'synchronized_standby_slots'
> > without filtering out duplicates.
> >
>
> May I know what your expectation is here? Would you like the check
> hook for synchronized_standby_slots to automatically resolve
> duplicates into a unique set of values, or should it detect duplicate
> entries and raise an error so that the user can correct the
> configuration?
>
> If we automatically resolve duplicates, the user would still see the
> GUC configured exactly as they specified, even though it would not
> function the same way internally. For example, if a user sets:
>
> FIRST 2 (s1, s1, s1, s2)
>
> it might internally be resolved to:
>
> FIRST 2 (s1, s2)
>
> However, when the user runs SHOW, it would still display the original
> configuration. This could give the user an incorrect impression of how
> the setting is actually being interpreted. Because of this, I feel we
> should treat duplicate entries as an invalid configuration and raise
> an error.
>
> As far as synchronous_standby_names is concerned, I can see that
> configurations such as:
>
> FIRST 2 (s1, s1, s1, s1)
>
> are currently accepted, which I don't think is correct either and
> should have been rejected, possibly resulted in the server startup
> failure.
>

My preference, and original intent, was to accept duplicate entries
and skip them internally. Doc can be updated to say 'duplicate entries
are skipped'. A server startup failure due to duplicate entries in a
GUC does not seem right to me. If the alter-system command fails due
to duplicate entries, that is still fine, but a startup failure seems
excessive. But let's see what others have to say on this.

thanks
Shveta