Re: pg_upgrade and logical replication
От | vignesh C |
---|---|
Тема | Re: pg_upgrade and logical replication |
Дата | |
Msg-id | CALDaNm00MF-d=4TToFxXtpzyZWRK_mq1_ih47wkjn5+reWN5PQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade and logical replication (vignesh C <vignesh21@gmail.com>) |
Ответы |
Re: pg_upgrade and logical replication
|
Список | pgsql-hackers |
On Fri, 15 Sept 2023 at 15:08, vignesh C <vignesh21@gmail.com> wrote: > > On Tue, 12 Sept 2023 at 14:25, Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.com> wrote: > > > > Dear Vignesh, > > > > Thank you for updating the patch! Here are some comments. > > > > Sorry if there are duplicate comments - the thread revived recently so I might > > lose my memory. > > > > 01. General > > > > Is there a possibility that apply worker on old cluster connects to the > > publisher during the upgrade? Regarding the pg_upgrade on publisher, the we > > refuse TCP/IP connections from remotes and port number is also changed, so we can > > assume that subscriber does not connect to. But IIUC such settings may not affect > > to the connection source, so that the apply worker may try to connect to the > > publisher. Also, is there any hazards if it happens? > > Yes, there is a possibility that the apply worker gets started and new > transaction data is being synced from the publisher. I have made a fix > not to start the launcher process in binary ugprade mode as we don't > want the launcher to start apply worker during upgrade. Another approach to solve this as suggested by one of my colleague Hou-san would be to set max_logical_replication_workers = 0 while upgrading. I will evaluate this and update the next version of patch accordingly. Regards, Vignesh
В списке pgsql-hackers по дате отправления: