Re: Separate GUC for replication origins

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>
Cc: "Peter Eisentraut" <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Separate GUC for replication origins
Date: 2025-03-05 00:54:26
Message-ID: 63905401-4e6f-4c36-9d7f-8b92d706c964@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 1, 2025, at 10:08 AM, Amit Kapila wrote:
> On Thu, Feb 13, 2025 at 6:48 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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.

It was my initial proposal. Of course, it breaks compatibility but it
forces the users to adopt this new GUC. It will be a smooth adoption
because if we use the same value as max_replication_slots it means
most of the scenarios will be covered (10 is a good start point for the
majority of replication scenarios in my experience).

However, Peter E suggested that it would be a good idea to have a
backward compatibility so I added it.

We need to decide which option we want:

1. no backward compatibility and max_replication_origin_sessions = 10 as
default value. It might break scenarios that have the number of
subscriptions greater than the default value.
2. backward compatibility for a certain number of releases until the
tools can be adjusted. However, the applications that use it were
adjusted as part of this patch. The drawback here is that once we
accept -1, we cannot remove it without breaking compatibility.

My preference was 1 but I'm fine with 2 too. Since it is a major
release, it is natural to introduce features that break things.

--
Euler Taveira
EDB https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2025-03-05 01:12:02 Re: Non-text mode for pg_dumpall
Previous Message Masahiko Sawada 2025-03-05 00:54:20 Re: Parallel heap vacuum