Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary

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

In response to

Browse pgsql-bugs by date

  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