On Fri, Jun 19, 2026 at 11:44 AM shveta malik <[email protected]> wrote: > > 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. >
Sure, please feel free to provide your feedback or suggestions whenever you have them. -- With Regards, Ashutosh Sharma.
