On Thu, Jul 9, 2026 at 5:07 PM Ajin Cherian <[email protected]> wrote:
>
> Thank you all for the comments. I have tried to address all the
> comments. I am not responding to each of them here. Based on the
> discussion above, I have retained the logic as mentioned by Shlok to
> compare active origins against max_active_replication_origins.
>
> Attaching v11 with all comments addressed.
>
Thank You Ajin, a few trivial comments:
1)
The new cluster must have
<link
linkend="guc-max-active-replication-origins"><varname>max_active_replication_origins</varname></link>
configured to a value greater than or equal to the number of
- subscriptions present in the old cluster.
+ replication origins present in the old cluster. The new cluster
must contain no replication origins.
This needs change as well.
2)
+ "LEFT OUTER JOIN pg_catalog.pg_replication_origin_status os ON
o.roident = os.local_id "
We may as well replace 'LEFT OUTER' with 'LEFT'. The 'OUTER' is
generally optional. But I leave it to you.
(The doc says: 'The words INNER and OUTER are optional in all forms.
INNER is the default; LEFT, RIGHT, and FULL imply an outer join.')
3)
+ * Also verify that the max_active_replication_origins configuration is
+ * enough for creating all the replication origins.
We should change this too.
4)
+ * Compare against the number of active origins in the old cluster not the
cluster not --> cluster, not
5)
get_replication_origin_info:
+ if (PQntuples(res) != 1)
+ pg_fatal("could not get the number of replication origins");
+ cluster->nrepl_origins = atoi(PQgetvalue(res, 0, 0));
Can we please leave a blank line after pg_fatal for better readability.
6)
+ * with an entry in pg_replication_origin_status. This can be less than
+ * nrepl_origins, since an origin can exist without ever becoming
A minor tweak suggestion:
'This can be less than ..' to:
This count can be smaller than nrepl_origins because a replication
origin can exist without ever becoming active
7)
/*
* get_subscription_info()
*
* Gets the information of subscriptions in the cluster.
*/
Originally this function was created to get number of subs and thus
was named as 'get_subscription_info'. I am not sure if this name is
still relevant. It is only getting 'retain_dead_tuples' info. Shall we
modify the comment at-least. Suggestion:
Determine whether any subscription has subretaindeadtuples enabled.
thanks
Shveta
