Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

On Fri, Jun 19, 2026 at 11:44 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Thu, Jun 18, 2026 at 12:42 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> 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 <shveta(dot)malik(at)gmail(dot)com> 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.