| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alexey Makhmutov <a(dot)makhmutov(at)postgrespro(dot)ru> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Standby server with cascade logical replication could not be properly stopped under load |
| Date: | 2025-05-22 23:47:40 |
| Message-ID: | aC-3nJekGZaAfNjQ@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-05-23 01:10:04 | Re: SIMILAR TO expressions translate wildcards where they shouldn't |
| Previous Message | Laurenz Albe | 2025-05-22 21:18:44 | SIMILAR TO expressions translate wildcards where they shouldn't |