Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

On Wed, Jun 3, 2026 at 4:30 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
> Hi Shveta,
>
> On Fri, May 15, 2026 at 9:28 AM shveta malik <shveta(dot)malik(at)gmail(dot)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 = '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