On Fri, Jul 17, 2026 at 3:17 PM shveta malik <[email protected]> wrote:
>
> On Thu, Jul 16, 2026 at 11:36 AM Ajin Cherian <[email protected]> wrote:
> >
> > On Fri, Jul 10, 2026 at 6:28 PM Shlok Kyal <[email protected]> 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

Attachment: v13-0001-Preserve-subscription-OIDs-during-pg_upgrade.patch
Description: Binary data

Attachment: v13-0002-Preserve-replication-origin-OIDs-during-pg_upgra.patch
Description: Binary data

Reply via email to