Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

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.

--
With Regards,
Ashutosh Sharma,