Re: Separate GUC for replication origins

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Euler Taveira <euler(at)eulerto(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Separate GUC for replication origins
Date: 2025-03-05 11:08:16
Message-ID: f8ca5699-8ea8-4c75-946a-30154301aa73@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11.02.25 21:25, Euler Taveira wrote:
> Here is another patch that only changes the GUC name to
> max_replication_origin_sessions.

I think the naming and description of this is still confusing.

What does this name mean? There is (I think) no such thing as a
"replication origin session". So why would there be a maximum of those?

The description in the documentation, after the patch, says "Specifies
how many replication origins (see Chapter 48) can be tracked
simultaneously". But Chapter 48 does not say anything about what it
means for a replication slot to be tracked. The only use of the word
tracked in that chapter is to say that replication slots do the tracking
of replication progress.

Both of these are confusing independently, but moreover we are now using
two different words ("sessions" and "tracked") for apparently the same
thing, but neither of which is adequately documented in those terms
anywhere else.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2025-03-05 11:12:57 Re: Incorrect result of bitmap heap scan.
Previous Message Dean Rasheed 2025-03-05 11:01:10 Re: Wrong results with subquery pullup and grouping sets