Hi, On Thu, Jun 4, 2026 at 9:14 AM shveta malik <[email protected]> wrote: > > 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. >
Okay, the attached patch adds the capability to automatically remove duplicate entries from the synchronized_standby_slots list. In N of M mode, if N > M after removing duplicate entries, an error is raised. This behavior has been documented, and test cases verifying the change have been added. A few other minor comments from [1] have also been addressed. Please have a look at the attached patches with these changes. [1] - https://www.postgresql.org/message-id/CAJpy0uCKGCkfCXCd%3DtsDH5e85x155LsdbZW46WpWfsZJUe82bw%40mail.gmail.com -- With Regards, Ashutosh Sharma.
0001-Refactor-syncrep-parsing-to-represent-bare-standby-l.patch
Description: Binary data
0003-Add-FIRST-N-and-N-.-priority-syntax-to-synchronized_.patch
Description: Binary data
0002-Add-ANY-N-semantics-to-synchronized_standby_slots.patch
Description: Binary data
