Re: Separate GUC for replication origins - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Separate GUC for replication origins
Date
Msg-id CAA4eK1LnauTQ7FVjUnOzNS_bwoW9DR4vgpwqXJ=yEKp29hwnWw@mail.gmail.com
Whole thread Raw
In response to Re: Separate GUC for replication origins  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Feb 13, 2025 at 6:48 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> Thank you for updating the patch! The patch looks mostly good to me.
>

+ /*
+ * Prior to PostgreSQL 18, max_replication_slots was used to set the
+ * number of replication origins. For backward compatibility, -1 indicates
+ * to use the fallback value (max_replication_slots).
+ */
+ if (max_replication_origin_sessions == -1)

Shouldn't we let users use max_replication_origin_sessions for
subscribers? Maintaining this mapping for a long time can create
confusion such that some users will keep using max_replication_slots
for origins, and others will start using
max_replication_origin_sessions. Such a mapping would be useful if we
were doing something like this in back-branches, but doing it in a
major version appears to be more of a maintenance burden.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Adding NetBSD and OpenBSD to Postgres CI
Next
From: Amit Kapila
Date:
Subject: Re: Licence preamble update