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
