Re: Separate GUC for replication origins

On Fri, 14 Mar 2025 at 06:25, Euler Taveira <euler@eulerto.com> wrote:
>
> On Thu, Mar 13, 2025, at 11:10 AM, vignesh C wrote:
>
> Few comments:
>
>
> Thanks for taking a look.
>
> 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.
>
>
> Fixed.
>
> 2) I felt max_replication_slots must be max_active_replication_origins
> here in logical-replication.sgml:
>
>
> Fixed.

Few comments:
1) Should we add a test case to verify that if
max_active_replication_origins is set to -1, it will use
max_replication_slots value:
+        * 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_active_replication_origins == -1)

Maybe since the default is -1, we can just add the verification in one
of the tests.

2) Should we consider about the origin's created by user using the
replication managment function at [1] or is it intentionally left out:
-    <link linkend="guc-max-replication-slots-subscriber"><varname>max_replication_slots</varname></link>
+    <link linkend="guc-max-active-replication-origins"><varname>max_active_replication_origins</varname></link>
     must be set to at least the number of subscriptions that will be added to
     the subscriber, plus some reserve for table synchronization.

[1] - https://www.postgresql.org/docs/current/replication-origins.html

Regards,
Vignesh