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. The attached patch implements this. Please have a look and let me know your thoughts. -- With Regards, Ashutosh Sharma.
v20260408-0001-Add-FIRST-ANY-and-N-.-syntax-support-to-synchronized.patch
Description: Binary data
