Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

On Wed, Apr 8, 2026 at 9:52 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Wed, Apr 8, 2026 at 7:39 AM Zhijie Hou (Fujitsu)
> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> >
> > If we only want to keep the slot active without advancing restart_lsn, we could
> > start a replication connection and then acquire the slot with the help of
> > the replication command: START_REPLICATION SLOT physical 0/01788488;
> >
> > E.g.,
> >
> > $standby->psql(
> > 'postgres',
> > qq[START_REPLICATION SLOT physical 0/01788488;],
> > replication => 'database');
> >
>
> I see your point. You are suggesting to use psql as a replication
> client (instead of a standby or pg_receivewal) that doesn’t send
> feedback to the walsender unlike walreceiver in case of standbys. In
> that case, the slot remains active but restart_lsn doesn’t advance,
> effectively leaving it active but lagging.
>
> While exploring this further, I found "019_replslot_limit.pl", which
> uses SIGSTOP and SIGCONT to pause and resume the walsender process.
> Pausing the walsender prevents it from streaming new WAL to the
> standby, resulting in a slot that is active but lagging. I followed a
> similar approach to build a test case that creates an active yet
> lagging standby slot. This slot does not satisfy priority/quorum
> conditions for synchronized_standby_slots, causing the logical
> walsender to wait for standby confirmation. Once SIGCONT is sent to
> the paused walsender, WAL streaming resumes and the logical walsender,
> which was blocked waiting for standby confirmation, proceeds.
>

I was just trying out Hou-san's suggestion and I came up with a
different approach. Attaching my modified test script.
If you think it is better, feel free to use it.

regards,
Ajin Cherian
Fujitsu Australia