Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

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.

The attached patch implements this. Please have a look and let me know
your thoughts.

--
With Regards,
Ashutosh Sharma.