Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

shveta malik <shveta.malik@gmail.com>

From: shveta malik <shveta.malik@gmail.com>
To: Ajin Cherian <itsajin@gmail.com>
Cc: Rui Zhao <zhaorui126@gmail.com>, Shlok Kyal <shlok.kyal.oss@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 <shveta.malik@gmail.com>
Date: 2026-06-24T05:21:20Z
Lists: pgsql-hackers
On Wed, Jun 24, 2026 at 10:39 AM shveta malik <shveta.malik@gmail.com> wrote:
>
>
> 2)
> replorigin_create_with_id():
>
> + if (SearchSysCacheExists1(REPLORIGNAME, roname_d))
> + ereport(ERROR,
> + errcode(ERRCODE_DUPLICATE_OBJECT),
> + errmsg("replication origin \"%s\" already exists", roname));
>
> Can this ever happen? IIUC, since new-cluster should not have any
> origin (as per the check introduced) and old cluster can not have
> duplicate names, we should not hit this error. Do we want to keep it
> as sanity check? If so, can we put a comment atop it.
>

Analyzed a bit more, with this change in patch002, we see an error change:

Without patch:
postgres=# SELECT pg_replication_origin_create('abcd');
 pg_replication_origin_create
------------------------------
                            1
postgres=# SELECT pg_replication_origin_create('abcd');
ERROR:  duplicate key value violates unique constraint
"pg_replication_origin_roname_index"
DETAIL:  Key (roname)=(abcd) already exists.

----

With patch:
postgres=#  SELECT pg_replication_origin_create('abcd');
 pg_replication_origin_create
------------------------------
                            1

postgres=# SELECT pg_replication_origin_create('abcd');
ERROR:  replication origin "abcd" already exists


So without the new check also, we can prevent duplicate name insertion
(even if that happens during upgrade, which I can not see  how). The
new error and the check is not wrong, but slightly redundant. Or let
me know if I am missing something.

thanks
Shveta



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Introduce replication progress tracking infrastructure.