Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

> All the above changes are updated in patch v10.
>
I noticed that we can create user defined replication origin even if the
total count of replication origins exceeds the max_active_replication_origins
Example:
postgres=# show max_active_replication_origins;
 max_active_replication_origins
--------------------------------
 1

postgres=# select * from pg_replication_origin;
 roident |  roname
---------+----------
       1 | pg_16387

postgres=# SELECT pg_replication_origin_create('origin1');
 pg_replication_origin_create
------------------------------
                            2

postgres=# select * from pg_replication_origin;
 roident |  roname
---------+----------
       1 | pg_16387
       2 | origin1

postgres=# select * from pg_replication_origin_status;
 local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+------------
        1 | pg_16387    | 0/00000000 | 0/00000000

The documentation for max_active_replication_origins says:
```
Specifies how many replication origins (see
<xref linkend="replication-origins"/>) can be tracked simultaneously,
effectively limiting how many logical replication subscriptions can
be created on the server. Setting it to a lower value than the current
number of tracked replication origins (reflected in
<link linkend="view-pg-replication-origin-status">pg_replication_origin_status</link>)
will prevent the server from starting. It defaults to 10. This parameter
can only be set at server start.
```
Since the user-created replication origin above is not
actively tracked in pg_replication_origin_status, no error is reported.

But with this patch, during pg_upgrade we are checking the
'max_active_replication_origins' against 'old_cluster.nrepl_origins'
+ if (old_cluster.nrepl_origins > max_active_replication_origins)
  pg_fatal("\"max_active_replication_origins\" (%d) must be greater
than or equal to the number of "
- "subscriptions (%d) in the old cluster",
- max_active_replication_origins, old_cluster.nsubs);
+ "replication origins (%d) in the old cluster",
+ max_active_replication_origins, old_cluster.nrepl_origins);

Since old_cluster.nrepl_origins counts all replication origins, including
user-created ones that may not be tracked, should this check instead compare
max_active_replication_origins with 'the number of rows in
pg_replication_origin_status in old cluster' (i.e., the number of
tracked replication origins)?

Thanks
Shlok Kyal