RE: pg_upgrade and logical replication

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Michael Paquier' <michael(at)paquier(dot)xyz>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: RE: pg_upgrade and logical replication
Date: 2023-09-26 05:46:55
Message-ID: TYAPR01MB5866AA6A1D0E936B311A0827F5C3A@TYAPR01MB5866.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Michael,

> > 1. Your approach must be back-patched to older versions which support logical
> > replication feature, but the oldest one (PG10) has already been
> unsupported.
> > We should not modify such a branch.
>
> This suggestion would be only for HEAD as it changes the behavior of -b.
>
> > 2. Also, "max_logical_replication_workers = 0" approach would be consistent
> > with what we are doing now and for upgrade of publisher patch.
> > Please see the previous discussion [1].
>
> Yeah, you're right. Consistency would be good across the board, and
> we'd need to take care of the old clusters as well, so the GUC
> enforcement would be needed as well. It does not strike me that this
> extra IsBinaryUpgrade would hurt anyway? Forcing the hand of the
> backend has the merit of allowing the removal of the tweak with
> max_logical_replication_workers at some point in the future.

Hmm, our initial motivation is to suppress registering the launcher, and adding
a GUC setting is sufficient for it. Indeed, registering a launcher may be harmful,
but it seems not the goal of this thread (changing -b workflow in HEAD is not
sufficient alone for the issue). I'm not sure it should be included in patch sets
here.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Lepikhov 2023-09-26 05:51:16 Re: POC: GROUP BY optimization
Previous Message Ashutosh Bapat 2023-09-26 05:41:51 Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)