Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication - Mailing list pgsql-hackers

On Tue, Jun 16, 2026 at 4:12 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> Hi,
>
> Thanks for reporting this. The attached patches address the issue and
> also incorporate the feedback from Shevta in [1].
>
> [1] - https://www.postgresql.org/message-id/CAJpy0uCKaqD-UfCX%3DQ5WkdtxUS8ZCJwLduegi5Etdx7gkV-02g%40mail.gmail.com
>

Thanks Ashutosh.

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.

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'


thanks
Shveta