Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

On Thu, Jul 9, 2026 at 5:07 PM Ajin Cherian <itsajin(at)gmail(dot)com> 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