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
v13-0001-Preserve-subscription-OIDs-during-pg_upgrade.patch
Description: Binary data
v13-0002-Preserve-replication-origin-OIDs-during-pg_upgra.patch
Description: Binary data
