From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Euler Taveira <euler(at)eulerto(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, 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-13 14:10:24 |
Message-ID: | CALDaNm259OHXsKdqZxMkFqV4pjmhf_Rt2u8WcC-7p5vnVFkkTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 13 Mar 2025 at 05:59, Euler Taveira <euler(at)eulerto(dot)com> wrote:
>
> On Wed, Mar 12, 2025, at 8:47 AM, vignesh C wrote:
>
> I reviewed the discussion on this thread and believe we now have an
> agreement on the design and GUC names. However, the patch still needs
> updates and extensive testing, especially considering its impact on
> backward compatibility. I'm unsure if this feature can be committed in
> the current CommitFest. If you're okay with it, we can move it to the
> next CommitFest. However, if you prefer to keep it, we can do our best
> to complete it and make a final decision at the end of the CommitFest.
>
>
> This is a mechanical patch. I was waiting if someone would object or suggest a
> better GUC name. It seems to me it isn't. The pre existing GUC
> (max_replication_slots) already has coverage. I don't know what additional
> tests you have in mind. Could you elaborate?
>
> I'm biased to say that it is one of the easiest patches to commit because it is
> just assigning a new GUC name for a pre existing functionality. If there is no
> interested in it, it will be moved to the next CF.
>
> I'm adding 2 patches. The 0001 contains the same version as the previous one
> but I renamed the GUC name to max_active_replication_origins. I'm also
> attaching 0002 if we decide that backward compatibility is not a concern so it
> removes it and assign 10 as the default value. I'm adding an additional suffix
> so CF bot doesn't grab 0002.
Few comments:
1) After selecting max_active_replication_origins setting in the
SELECT query having order by, the first record returned will be the
one with max_active_replication_origins, rather than the second
record, because max_active_replication_origins appears before
max_logical_replication_workers in the order.
res = PQexec(conn,
"SELECT setting FROM
pg_catalog.pg_settings WHERE name IN ("
"'max_logical_replication_workers', "
- "'max_replication_slots', "
+ "'max_active_replication_origins', "
"'max_worker_processes', "
"'primary_slot_name') "
"ORDER BY name");
The code below in the function should be modified accordingly:
max_lrworkers = atoi(PQgetvalue(res, 0, 0));
max_reporigins = atoi(PQgetvalue(res, 1, 0));
max_wprocs = atoi(PQgetvalue(res, 2, 0));
2) I felt max_replication_slots must be max_active_replication_origins
here in logical-replication.sgml:
The new cluster must have
<link linkend= guc-max-replication-slots
><varname>max_replication_slots</varname></link>
configured to a value greater than or equal to the number of
subscriptions present in the old cluster.
Regards,
Vignesh
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2025-03-13 14:15:01 | Re: Implement waiting for wal lsn replay: reloaded |
Previous Message | Greg Sabino Mullane | 2025-03-13 14:03:41 | Re: Allow default \watch interval in psql to be configured |