Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

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.

--
With Regards,
Ashutosh Sharma.