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-22T23:47:40Z
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. > > PG 16 does not have the slot synchronization logic, so its implementation of > GetStandbyFlushRecPtr is slightly different and comments need to be updated > to reflect this discrepancy as well. So, here is a variant of the same patch > updated to be compatible with PG 16: > 0002-Use-only-replayed-position-as-target-flush-point-3-pg-16.patch Hmm. The scenario you are pointing at with a mix of cascading logical and physical standbys is tricky enough that I think this warrants having a test in the long-run. Do you think that it would be possible to sort something out with ordered actions taken during the shutdown sequences at least for HEAD? Are v15 and older versions things that we should worry about when using setups made of physical standbys? -- 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