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

From Peter Eisentraut
Subject Re: Separate GUC for replication origins
Date
Msg-id 686a66b5-0ba0-44a2-bbb1-a9d1a2dd254f@eisentraut.org
Whole thread Raw
In response to Re: Separate GUC for replication origins  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Separate GUC for replication origins
List pgsql-hackers
On 07.03.25 04:51, Amit Kapila wrote:
>>> I agree that the originally proposed name max_replication_origins is not
>>> good, because you can "create" (using pg_replication_origin_create())
>>> more than the configured maximum.  What is the term for what the setting
>>> actually controls?  How many are "active"?  "In use"?  Per session?  etc.
>>>
>> It controls the number of active sessions using origin. The idea is
>> that to track replication progress via replication_origin we need to
>> do replorigin_session_setup(). If you look in the code, we have used
>> the term replorigin_session* in many places, so we thought of naming
>> this as max_replication_origin_sessions. But the other options could
>> be max_active_replication_origins or max_replication_origins_in_use.
>>
>>
>> The word "session" is correlated to "replication origin" but requires some
>> knowledge to know the replication progress tracking design. The word "active"
>> can express the fact that it was setup and is currently in use. I vote for
>> max_active_replication_origins.
>>
> Sounds reasonable. Let's go with max_active_replication_origins then,
> unless people think otherwise.

Is that maximum active for the whole system, or maximum active per 
session, or maximum active per created origin, or some combination of these?




pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: encode/decode support for base64url
Next
From: Andres Freund
Date:
Subject: Re: Refactoring postmaster's code to cleanup after child exit