Re: Separate GUC for replication origins
От | Amit Kapila |
---|---|
Тема | Re: Separate GUC for replication origins |
Дата | |
Msg-id | CAA4eK1LnauTQ7FVjUnOzNS_bwoW9DR4vgpwqXJ=yEKp29hwnWw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Separate GUC for replication origins (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Separate GUC for replication origins
|
Список | 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 по дате отправления: