MIME-Version: 1.0
References: 
 <CAJpy0uBT8JbEGE0xvm-Wxh1g_VVgC=whKqChZo-uB+VOa_YCTw@mail.gmail.com>
 <CAE9k0Pkk6q72X3Rc3MUo7PxU46UcCzLfMhM02PGDUmAue9cDGg@mail.gmail.com>
 <TY4PR01MB17718104B91F2945BE727467694102@TY4PR01MB17718.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <TY4PR01MB17718104B91F2945BE727467694102@TY4PR01MB17718.jpnprd01.prod.outlook.com>
From: Ashutosh Sharma <ashu.coek88@gmail.com>
Date: Thu, 4 Jun 2026 14:56:59 +0530
Message-ID: 
 <CAE9k0P=dgCEaKE6+vSCQp8TgrYOi_RqQkDTScdWzFSECsPQn9w@mail.gmail.com>
Subject: Re: synchronized_standby_slots behavior inconsistent with
 quorum-based synchronous replication
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: shveta malik <shveta.malik@gmail.com>,
 Amit Kapila <amit.kapila16@gmail.com>,
	Ajin Cherian <itsajin@gmail.com>,
 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/CAE9k0P%3DdgCEaKE6%2BvSCQp8TgrYOi_RqQkDTScdWzFSECsPQn9w%40mail.gmail.com>
Precedence: bulk

Hi,

Thanks for your feedback.

On Thu, Jun 4, 2026 at 1:54=E2=80=AFPM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Thursday, June 4, 2026 3:36 PM Ashutosh Sharma <ashu.coek88@gmail.com>=
 wrote:
> > On Thu, Jun 4, 2026 at 9:14=E2=80=AFAM shveta malik <shveta.malik@gmail=
.com>
> > wrote:
> > >
> > > On Wed, Jun 3, 2026 at 4:30=E2=80=AFPM Ashutosh Sharma
> > <ashu.coek88@gmail.com> wrote:
> > > > 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. A=
s an
> > > > > example, if user ends up giving one entry twice in priority
> > > > > configuration, then we will end up waiting on one slot twice rath=
er
> > > > > 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 n=
ot
> > > > > exist. It consumes standby_1 twice and thinks that the required n=
umber
> > > > > 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 o=
n standby_2
> > > > >
> > > > > This is perhaps because 'synchronous_standby_names ' waits on act=
ive
> > > > > WAL senders rather than repeated strings in configuration. But ou=
r
> > > > > 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 duplica=
te
> > > > entries and raise an error so that the user can correct the
> > > > configuration?
> > > >
> > > > If we automatically resolve duplicates, the user would still see th=
e
> > > > 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 origin=
al
> > > > 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 rais=
e
> > > > 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 entrie=
s
> > > 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.
> > >
> >
> > Okay, the attached patch adds the capability to automatically remove
> > duplicate entries from the synchronized_standby_slots list.
>
> Thanks for updating the patch.
>
> I agree with Shveta that reporting an ERROR is not ideal. I also think it=
 (ERROR) would
> be inconsistent with existing GUCs, as most of them, such as
> synchronous_standby_names, search_path, and session_preload_libraries, do=
 not
> enforce uniqueness.
>
> The most similar GUC, synchronous_standby_names, also clarifies this in t=
he
> documentation:
>
>         " There is no mechanism to enforce uniqueness of standby names. I=
n case of
>         duplicates one of the matching standbys will be considered as hig=
her priority,
>         though exactly which one is indeterminate."[1]
>
> > In N of M
> > mode, if N > M after removing duplicate entries, an error is raised.
>
> I'm not entirely sure about this case. It seems similar to when the numbe=
r of
> specified slots is less than N (in ANY N or FIRST N), given that we want =
to skip
> duplicate slots. In that situation, the natural behavior to me would be t=
o
> simply block replication rather than raise an error. And
> synchronous_standby_names would also simply block the transaction in this=
 case.
>

For duplicate entries themselves, I agree with the direction of not
raising an error. Silently normalizing duplicates is reasonable for
this GUC, especially if we document it clearly. A repeated slot name
does not add any new information, so treating it as =E2=80=9Csame slot list=
ed
twice by mistake=E2=80=9D is practical.

But for N > M after deduplication, I would still lean toward raising an err=
or.

Why I=E2=80=99d separate those cases:

1) Duplicate entries looks like a harmless normalization problem. ANY
2 (a, a, b) can be normalized to ANY 2 (a, b) without changing the
user=E2=80=99s apparent intent much.

2) N > M after deduplication is not a transient runtime state. ANY 2
(a, a) becomes one unique slot. That configuration can never succeed
unless the config itself changes. Blocking forever turns a static
configuration mistake into an operational liveness problem.

3) N > M after deduplication is different from ordinary =E2=80=9Cnot enough
standbys are currently available=E2=80=9D. If we configure ANY 2 (a, b) and
only a is currently caught up, blocking makes sense because the
situation may resolve at runtime. If we configure ANY 2 (a, a) and
duplicates are ignored, there is no possible future runtime in which
it succeeds without editing the GUC. That is why I think erroring is
better.

On the synchronous_standby_names comparison, I do not think it is
fully analogous. The quoted documentation is about there being no
reliable way to enforce uniqueness of standby names in the live
system, because those names are matched against runtime standbys and
the result can be indeterminate. Here, synchronized_standby_slots
names concrete replication slots, which are stable object identifiers.
Duplicate config entries are detectable and normalizable
deterministically at GUC parse time. That gives us a cleaner option
than synchronous_standby_names has.

So my preferred behavior would be:

1) duplicate names: normalize, do not error
2) after normalization, if num_sync > unique_slots: error immediately

--
With Regards,
Ashutosh Sharma.