Re: Standby server with cascade logical replication could not be properly stopped under load
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, shveta malik <shveta.malik@gmail.com>, Ajin Cherian <itsajin@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-05-28T07:35:58Z
Lists: pgsql-bugs
On Thu, May 22, 2025 at 09:22:02PM +0300, Alexey Makhmutov wrote:
> I've tried to update method comment as well in the updated patch:
> 0001-Use-only-replayed-position-as-target-flush-point-3-pg-master.patch.
> The same patch could be applied on top of PG 17 as well.
+ if (MyWalSnd->kind == REPLICATION_KIND_PHYSICAL)
+ {
+ TimeLineID receiveTLI;
+ XLogRecPtr receivePtr = GetWalRcvFlushRecPtr(NULL, &receiveTLI);
+
+ if (receiveTLI == replayTLI && receivePtr > result)
+ result = receivePtr;
+ }
Looking at the patch, I am not much a fan of looking at MyWalSnd in
GetStandbyFlushRecPtr() which does not have such a dependency yet, to
then decide if the LSN retrieved by GetWalRcvFlushRecPtr() should be
removed or used.
Wouldn't it be better to extend GetStandbyFlushRecPtr() so as the
caller can directly decide if they want to include in the maths the
last LSN flushed by the WAL receiver, depending on the code path where
the routine is called? That makes for a larger patch, of course, but
it removes the need to look at MyWalSnd inside
GetStandbyFlushRecPtr().
--
Michael
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use replay LSN as target for cascading logical WAL senders
- 5e6d561bc14d 16.10 landed
- 87be749c716a 17.6 landed
- 5231ed8262c9 18.0 landed