On Tue, Sep 16, 2025 at 9:23 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> 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.
Thank you for drafting the patch. It looks good to me.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
