On Wed, Apr 8, 2026 at 6:23 PM Ajin Cherian <[email protected]> wrote: > > On Wed, Apr 8, 2026 at 9:52 PM Ashutosh Sharma <[email protected]> wrote: > > > > Hi, > > > > On Wed, Apr 8, 2026 at 7:39 AM Zhijie Hou (Fujitsu) > > <[email protected]> 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
