On Wed, Apr 8, 2026 at 6:23 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Wed, Apr 8, 2026 at 9:52 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> >
> > Hi,
> >
> > On Wed, Apr 8, 2026 at 7:39 AM Zhijie Hou (Fujitsu)
> > <houzj.fnst@fujitsu.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. Would you be able to share the timing of test (complete
file) as well with this change in testfile.
thanks
Shveta
