public inbox for [email protected]
help / color / mirror / Atom feedFrom: shveta malik <[email protected]>
To: Ashutosh Sharma <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Hou, Zhijie/侯 志杰 <[email protected]>
Cc: Ajin Cherian <[email protected]>
Cc: SATYANARAYANA NARLAPURAM <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: shveta malik <[email protected]>
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Date: Thu, 4 Jun 2026 09:13:52 +0530
Message-ID: <CAJpy0uBT8JbEGE0xvm-Wxh1g_VVgC=whKqChZo-uB+VOa_YCTw@mail.gmail.com> (raw)
In-Reply-To: <CAE9k0P=GC51G2g_odG_pvp2Tbg9Ks=tNHwvAZQuQpb0na2JmkA@mail.gmail.com>
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>
On Wed, Jun 3, 2026 at 4:30 PM Ashutosh Sharma <[email protected]> wrote:
>
> Hi Shveta,
>
> On Fri, May 15, 2026 at 9:28 AM shveta malik <[email protected]> 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 = '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 = 'FIRST 2 (standby_1,
> > standby_1, standby_2, standby_3)';
> > insert into tab1 values (10), (20), (30); ----> This will wait on standby_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
view thread (25+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
In-Reply-To: <CAJpy0uBT8JbEGE0xvm-Wxh1g_VVgC=whKqChZo-uB+VOa_YCTw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox