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. regards, Ajin Cherian Fujitsu Australia
053_synchronized_standby_slots_quorum.pl
Description: Binary data
