Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

On Fri, Jul 17, 2026 at 3:17 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Thu, Jul 16, 2026 at 11:36 AM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> >
> > On Fri, Jul 10, 2026 at 6:28 PM Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> wrote:
> > >
> > >
> > > Thanks,
> > > Shlok Kyal
> >
> > Thanks for all the comments. Here's an updated patch addressing these comments.
> >
>
> Thanks Ajin. A few trivial comments:

I've addressed all the above comments.

There was also a CFbot failure on linux machine as below:

# Failed test 'run of pg_upgrade where the new cluster has
insufficient max_active_replication_origins status (got 0 vs expected
1)'
[02:43:22] t/001_basic.pl ................... ok 180 ms ( 0.00
usr 0.00 sys + 0.11 cusr 0.04 csys = 0.15 CPU)
# at t/004_subscription.pl line 60.

I don't see the same error on my machine, but I think the problem is
because the node is stopped too soon after the subscription is
created. So I've added logic to wait until the replication origin
becomes active.

+# Wait until the apply worker sets up the replication origin, making it
+# active. Otherwise, stopping the old cluster too early could leave the
+# origin inactive, causing the check below to see no active replication
+# origins and fail.
+$old_sub->poll_query_until('postgres',
+ "SELECT count(*) > 0 FROM pg_replication_origin_status")
+ or die "Timed out while waiting for the replication origin to become active";
+
$old_sub->stop;

regards,
Ajin Cherian
Fujitsu Australia