Dear Amit, > This sounds like a reasonable way to address the reported problem.
OK, thanks!
> Justin, do let me know if you think otherwise?
>
> Comment:
> ===========
> *
> -# Setup an enabled subscription to verify that the running status and
> failover
> -# option are retained after the upgrade.
> +# Setup a subscription to verify that the failover option are retained after
> +# the upgrade.
> $publisher->safe_psql('postgres', "CREATE PUBLICATION regress_pub1");
> $old_sub->safe_psql('postgres',
> - "CREATE SUBSCRIPTION regress_sub1 CONNECTION '$connstr' PUBLICATION
> regress_pub1 WITH (failover = true)"
> + "CREATE SUBSCRIPTION regress_sub1 CONNECTION '$connstr'
> PUBLICATION
> regress_pub1 WITH (failover = true, enabled = false)"
> );
>
> I think it is better not to create a subscription in the early stage
> which we wanted to use for the success case. Let's have separate
> subscriptions for failure and success cases. I think that will avoid
> the newly added ALTER statements in the patch.
I made a patch to avoid creating objects as much as possible, but it
may lead some confusion. I recreated a patch for creating pub/sub
and dropping them at cleanup for every test cases.
PSA a new version.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/
v3-0001-Fix-testcase.patch
Description: v3-0001-Fix-testcase.patch
