pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Nathan Bossart <nathandbossart@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Nazneen Jafri <jafrinazneen@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary
Date: Tue, 16 Sep 2025 23:23:18 -0500
Message-ID: <aMo3tsESKXh6MCVp@nathan> (raw)
In-Reply-To: <CAD21AoB3kcrVnTxHX+F=MOt_DWHdKFBLKaBBeOcsUyW6jWEMfQ@mail.gmail.com>
References: <CA+m5N8uciiyzVOBb+ncadQutLoMOFaqN13Phq+r_neZm2vd5gQ@mail.gmail.com>
	<CAD21AoAWGp5q9w7bN024NGT7QL=1Vw3PcqGBLbE35XGnT_JzpQ@mail.gmail.com>
	<aMog06qbmvLLcFSw@nathan>
	<CAD21AoB3kcrVnTxHX+F=MOt_DWHdKFBLKaBBeOcsUyW6jWEMfQ@mail.gmail.com>

On Tue, Sep 16, 2025 at 09:05:33PM -0700, Masahiko Sawada wrote:
> On Tue, Sep 16, 2025 at 7:45 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> I haven't tried reproducing it on older versions (with
>> max_replication_slots instead of max_active_replication_origins), but after
>> looking at the code for a bit, I'm growing skeptical that this is new to
>> v18.
> 
> Right, it's actually not a new behavior to v18 as we can reproduce it
> with max_replication_slots. I guess that the reason why we didn't
> require standbys to set max_replication_slots no smaller than the
> primary's value is that in principle the maximum number of replication
> slots is not related to the recovery work. max_replication_slots juse
> used to be re-used for the maximum number of active replication
> origins for the sake of simplicity. Now that we have separated the
> maximum number of active replication origins from
> max_replication_slots, it seems to me that
> max_active_replication_origins is now clearly related to the recovery.

Given that it's existing behavior, I'm not seeing a strong reason to try to
do anything about this for v18.  But I could be misunderstanding the nuance
here.

>> In any case, the PANIC provides a clear error message, which is
>> roughly the same as what we'd say with the control file approach, right?
> 
> Yes. With the control file approach, we raise a FATAL (or pause the
> recovery with a WARNING) instead of PANIC.

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.

-- 
nathan


Attachments:

  [text/plain] v1-0001-max_active_replication_origins-fix.patch (0B, ../aMo3tsESKXh6MCVp@nathan/2-v1-0001-max_active_replication_origins-fix.patch)
  download

view thread (8+ messages)  latest in thread

Message-ID: <aMo3tsESKXh6MCVp@nathan>
Permalink:  ../aMo3tsESKXh6MCVp@nathan/
Also on:    postgresql.org/message-id/aMo3tsESKXh6MCVp@nathan

 ·  · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: nathandbossart@gmail.com, sawada.mshk@gmail.com, jafrinazneen@gmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary
  In-Reply-To: <aMo3tsESKXh6MCVp@nathan>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox