From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
---|---|
To: | "Nathan Bossart" <nathandbossart(at)gmail(dot)com>, "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | "Nazneen Jafri" <jafrinazneen(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary |
Date: | 2025-09-17 22:34:56 |
Message-ID: | fb6cbb5a-43e0-4da0-9008-3e583b41a230@app.fastmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Sep 17, 2025, at 1:23 AM, Nathan Bossart wrote:
> I drafted up what that would look like. One very small nitpick is that it
> messes up the alignment of the pg_controldata output. Otherwise, it seems
> pretty straightforward.
>
As Masahiko said this behavior is not new in v18 so I wouldn't consider fix it
to v18.
I don't think your patch works for one detail: StartupReplicationOrigin() is
called earlier than CheckRequiredParameterValues(). The
StartupReplicationOrigin() uses max_active_replication_origins to emit the
PANIC message. I didn't check the implications to postpone the
StartupReplicationOrigin(). Maybe an ugly solution is to check the
max_active_replication_origins inside or even before calling
StartupReplicationOrigin().
I'm attaching a script that I used to simulate the issue. Change the GUC name
to simulate the issue in a pre v18.
--
Euler Taveira
EDB https://www.enterprisedb.com/
Attachment | Content-Type | Size |
---|---|---|
test-maro.sh | application/x-shellscript | 3.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-09-18 00:24:49 | Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c |
Previous Message | David Rowley | 2025-09-17 22:32:35 | Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos |