Re: pg_upgrade and logical replication - Mailing list pgsql-hackers

From vignesh C
Subject Re: pg_upgrade and logical replication
Date
Msg-id CALDaNm00MF-d=4TToFxXtpzyZWRK_mq1_ih47wkjn5+reWN5PQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade and logical replication  (vignesh C <vignesh21@gmail.com>)
Responses Re: pg_upgrade and logical replication
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Improve the log message output of basic_archive when basic_archive.archive_directory parameter is not set
Next
From: Heikki Linnakangas
Date:
Subject: Re: Unlogged relation copy is not fsync'd