RE: pg_upgrade and logical replication
| От | Hayato Kuroda (Fujitsu) |
|---|---|
| Тема | RE: pg_upgrade and logical replication |
| Дата | |
| Msg-id | TYCPR01MB12077B16EEDA360BA645B96F8F54C2@TYCPR01MB12077.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: pg_upgrade and logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: pg_upgrade and logical replication
|
| Список | pgsql-hackers |
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/
Вложения
В списке pgsql-hackers по дате отправления: