Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

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.

thanks
Shveta