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

From vignesh C
Subject Re: pg_upgrade and logical replication
Date
Msg-id CALDaNm2g9ZKf=y8X6z6MsLCuh8WwU-=Q6pLj35NFi2M5BZNS_A@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade and logical replication  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_upgrade and logical replication
List pgsql-hackers
On Tue, 19 Sept 2023 at 11:49, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Sep 15, 2023 at 04:51:57PM +0530, vignesh C wrote:
> > 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.
>
> In the context of an upgrade, any node started is isolated with its
> own port and a custom unix domain directory with connections allowed
> only through this one.
>
> Saying that, I don't see why forcing max_logical_replication_workers
> to be 0 would be necessarily a bad thing to prevent unnecessary
> activity on the backend.  This should be a separate patch built on
> top of the main one, IMO.

Here is a patch to set max_logical_replication_workers as 0 while the
server is started to prevent the launcher from being started. Since
this configuration is present from v10, no need for any version check.
I have done upgrade tests for v10-master, v11-master, ... v16-master
and found it to be working fine.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: pg_ctl start may return 0 even if the postmaster has been already started on Windows