Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication

On Wed, Apr 8, 2026 at 6:23 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> 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.
>

Thanks Ajin for sharing your version based on Hou-san's suggestions.
This approach looks more robust and is also platform independent, so
in my view we should proceed with it. I’ll review the changes,
incorporate them into the main patch, and share an updated patch.

--
With Regards,
Ashutosh Sharma.