On Thu, Jun 18, 2026 at 12:42 PM Ashutosh Sharma <[email protected]> wrote: > > Hi Shveta, > > Thanks again for your review comments, please find my responses inline below: > > On Thu, Jun 18, 2026 at 11:14 AM shveta malik <[email protected]> wrote: > > > > 1) > > + > > +# FIRST duplicates must also not create extra priority positions. > > +$primary->adjust_conf('postgresql.conf', 'synchronized_standby_slots', > > + "'FIRST 2 (sb1_slot, sb1_slot, sb2_slot)'"); > > +$primary->reload; > > > > I think either of ANY or FIRST is enough to cover the duplicate > > removal path. We can remove any one of these tests if you agree. > > > > It can be. From a code coverage perspective, I don't see any impact. > However, FIRST and ANY represent different semantics. Although they > share the same underlying logic for filtering duplicate entries, I > felt it would still be beneficial to have a test case that explicitly > demonstrates that duplicate removal works correctly with both options. > > That said, if you feel this makes the test file a bit heavier than > necessary, I'm happy to remove it and keep the test suite lighter. > > > 2) > > I tried running tests. Ran it 6 times. 3 times, it finished in 7-8 > > seconds, while in the rest of the runs, it took 25 seconds each. > > > > Please run this on your machine and let me know if the behaviour is same. > > > > In the log file of the run (and other similar runs), where execution > > time is longer, most of the time is spent here: > > > > primary.log: > > 2026-06-18 10:50:03.687 IST postmaster[49574] LOG: received SIGHUP, > > reloading configuration files > > 2026-06-18 10:50:03.688 IST postmaster[49574] LOG: parameter > > "synchronized_standby_slots" changed to "" > > 2026-06-18 10:50:21.514 IST walsender[49792] > > 054_synchronized_standby_slots_quorum.pl LOG: released physical > > replication slot "sb1_slot" > > 2026-06-18 10:50:21.522 IST client backend[49801] > > 054_synchronized_standby_slots_quorum.pl LOG: statement: SELECT > > pg_logical_slot_get_changes('logical_failover', NULL, NULL); > > > > Standby's log: > > 2026-06-18 10:50:02.470 IST client backend[49768] > > 054_synchronized_standby_slots_quorum.pl LOG: statement: WAIT FOR LSN > > '0/030003C8' WITH (MODE 'standby_replay', timeout '180s', no_throw); > > 2026-06-18 10:50:03.644 IST client backend[49790] > > 054_synchronized_standby_slots_quorum.pl LOG: statement: WAIT FOR LSN > > '0/03000448' WITH (MODE 'standby_replay', timeout '180s', no_throw); > > 2026-06-18 10:50:21.696 IST postmaster[49614] LOG: received fast > > shutdown request > > ~~ > > > > Notice the time jump from '10:50:02' to ' 10:50:21' > > > > I ran the test case 7–8 times, and each execution completed in roughly > 6–9 seconds on my machine. Please check the attached file with test > results. >
Okay, then it could be my slow VM issue. The patch is in good shape. I will pause my review here and resume when the committer (or others) starts participating. thanks Shveta
