Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: shveta malik <shveta.malik@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Ajin Cherian <itsajin@gmail.com>, Zsolt Parragi <zsolt.parragi@percona.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-08T10:42:11Z
Lists: pgsql-hackers
On Wed, Jul 8, 2026 at 3:37 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> > Fair point but isn't it sufficient to check the tracked_origins rather
> > than all origins? In docs of max_active_replication_origins, we say:
> > "Setting it to a lower value than the current number of tracked
> > replication origins (reflected in pg_replication_origin_status) will
> > prevent the server from starting." which suggests here we should have
> > a tight check of tracked_origins against
> > max_active_replication_origins.
>
> Basically it sounds good, but it can slightly change the behavior if the old node
> has some subscriptions which have never been enabled. Till now, we just counted
> the number of subscriptions, thus we took into account them [1]. But after the
> patch they can be ignored; IIUC pg_upgrade can succeed in the case.
>
> If the change is OK, we can proceed with your (and Shlok-san's) idea.
>
> [1]: reproducer is below.
> 1. initialized old node with max_active_replication_origins=1
> 2. created two subscriptions with (connect=false)
> 3. initialized new node with max_active_replication_origins=1
> 4. ran pg_upgrade and it did error-out
>
> ```
> $ pg_upgrade -b /usr/local/pgsql/bin/ -d old/ -D new/ -U postgres
> Performing Consistency Checks
> -----------------------------
> ...
> Checking new cluster configuration for subscriptions
> "max_active_replication_origins" (1) must be greater than or equal to the number of subscriptions (2) in the old cluster
> Failure, exiting
> ```
>

Yes, I understand this case but I feel the old check is more
restrictive than required. We might want to even back-patch this small
part in future if we see any such user complaint.

-- 
With Regards,
Amit Kapila.



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.