Re: Standby server with cascade logical replication could not be properly stopped under load
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
Cc: shveta malik <shveta.malik@gmail.com>, Ajin Cherian <itsajin@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-05-22T15:31:40Z
Lists: pgsql-bugs
Hi, On Thu, May 22, 2025 at 04:29:37PM +0300, Alexey Makhmutov wrote: > Hi Ajin and Shveta, thank you for looking at this issue. > > On 5/22/25 12:48, Ajin Cherian wrote: > > > Just a small comment: can you explicitly mention in the comments that > > "for logical replication we can only send records that have already > > been replayed else we might get stuck in shutdown" or something to > > that effect as that distinction is important for future developers in > > this area. > > Thank you. I've expanded the comment to make it more verbose to clarify > expected logic in this case. > Updated patch is attached as > '0001-Use-only-replayed-position-as-target-flush-point-2.patch'. Thanks for the report! I agree with your analysis and I think that your proposed fix make sense. I wonder if the comment on top of GetStandbyFlushRecPtr() could be updated a bit though. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
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