Re: Standby server with cascade logical replication could not be properly stopped under load
Ajin Cherian <itsajin@gmail.com>
From: Ajin Cherian <itsajin@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alexey Makhmutov <a.makhmutov@postgrespro.ru>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
shveta malik <shveta.malik@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-05-29T10:28:01Z
Lists: pgsql-bugs
On Thu, May 29, 2025 at 5:02 PM Michael Paquier <michael@paquier.xyz> wrote: > nd master versions. > > Yeah, I think that this is a sensible move. Documenting the reason > why GetXLogReplayRecPtr() is called is important, but the comment you > are suggesting could be better, IMO, say: > "For cascading logical WAL senders, we use the replay LSN rather than > the flush LSN, as decoding would only happen with records already > replayed. This distinction is important especially during the > shutdown sequence, as cascading logical WAL senders can only catch up > with records that have been already replayed, not flushed." > > That feels that I'm repeating myself a bit twice if formulated this > way. If you have a better suggestion, feel free.. > > > I think this new fix is much better and cleaner. A suggestion for the comment: "For cascading logical WAL senders, we use the replay LSN instead of the flush LSN, since logical decoding on a standby only processes WAL that has been replayed. This distinction becomes particularly important during shutdown, as new WAL is no longer replayed and the last replayed LSN marks the furthest point up to which decoding can proceed." regards, Ajin Cherian Fujitsu Australia
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