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
