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 по дате отправления: