Re: [PATCH] Preserve replication origin OIDs in pg_upgrade
Nisha Moond <nisha.moond412@gmail.com>
From: Nisha Moond <nisha.moond412@gmail.com>
To: Ajin Cherian <itsajin@gmail.com>
Cc: Shlok Kyal <shlok.kyal.oss@gmail.com>,
shveta malik <shveta.malik@gmail.com>, Zsolt Parragi <zsolt.parragi@percona.com>, vignesh C <vignesh21@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
shveta malik <shvetamalik@gmail.com>
Date: 2026-06-17T10:59:11Z
Lists: pgsql-hackers
On Wed, Jun 17, 2026 at 2:49 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
> I have addressed the comments in v8 (attached). I've also now taken
> out the check for PG17 on old cluster and now all clusters which have
> replication origins are migrated.
Hi Ajin, Thanks for the patches.
I have started reviewing the patches. Please find a few initial
comments below (from v7 review, still applicable to v8):
1) Patch-002: pg_dump.c
+ if (dopt->binary_upgrade && subinfo->subenabled &&
fout->remoteVersion >= 170000)
{
- if (subinfo->suboriginremotelsn)
- {
- /*
- * Preserve the remote_lsn for the subscriber's replication
I could not find any usage of subinfo[i].suboriginremotelsn anymore.
It seems to be dead code now. Can we remove it?
~~~
2) Patch-002 : binary_upgrade_create_replication_origin()
- PG_RETURN_VOID();
+ node_oid = PG_GETARG_OID(0);
+
+ if (node_oid == InvalidOid || node_oid > PG_UINT16_MAX)
+ ereport(ERROR,
+ errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("replication origin ID %u is out of range", node_oid));
+
The above range check allows PG_UINT16_MAX, but that value is not part
of the valid replication origin ID range.
In origin.h:
#define DoNotReplicateId PG_UINT16_MAX
And we already ensure "ReplOriginId != DoNotReplicateId" everywhere
else. Would something like the below be more appropriate?
if (node_oid == InvalidReplOriginId || node_oid >= DoNotReplicateId)
ereport(ERROR, ...
~~~
3) I think we should add some additional details in
logical-replication.sgml, especially under <title>Prepare for
Subscriber Upgrades</title>.
Some suggestions:
3a) Since all replication origins are now migrated, this:
"...greater than or equal to the number of subscriptions present in
the old cluster."
could become:
"...greater than or equal to the number of replication origins
present in the old cluster."
3b) We should also mention:
The new cluster must contain no replication origins.
--
Thanks,
Nisha
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Introduce replication progress tracking infrastructure.
- 5aa2350426c4 9.5.0 cited