Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
shveta malik <shveta.malik@gmail.com>
From: shveta malik <shveta.malik@gmail.com>
To: Ajin Cherian <itsajin@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Japin Li <japinli@hotmail.com>, surya poondla <suryapoondla4@gmail.com>, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
shveta malik <shveta.malik@gmail.com>
Date: 2026-04-09T03:31:26Z
Lists: pgsql-hackers
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