From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Separate GUC for replication origins |
Date: | 2025-03-07 14:47:53 |
Message-ID: | 686a66b5-0ba0-44a2-bbb1-a9d1a2dd254f@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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?
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-03-07 14:53:16 | Re: Refactoring postmaster's code to cleanup after child exit |
Previous Message | Aleksander Alekseev | 2025-03-07 14:40:54 | Re: encode/decode support for base64url |