Re: A recent message added to pg_upgade

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: A recent message added to pg_upgade
Date: 2023-11-02 06:02:26
Message-ID: ZUM7cl5BTydRmbQM@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 02, 2023 at 02:32:07PM +1100, Peter Smith wrote:
> On Thu, Nov 2, 2023 at 2:25 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>> Checking this patch yesterday prompted me to create a new thread
>> questioning the inconsistencies of the "GUC names in messages". In
>> that thread, Tom Lane replied and gave some background information [1]
>> about the GUC name embedding versus substitution. In hindsight, I
>> think your original message was fine as-is, but there seem to be
>> examples of every kind of style, so whatever you do would have some
>> precedent.
>>
>> The patch v4 LGTM.
>
> To clarify, all the current code LGTM, but the patch is still missing
> a guc_hook test case, right?

- NULL, NULL, NULL
+ check_max_slot_wal_keep_size, NULL, NULL

FWIW, I am +-0 with what you are proposing here. I don't quite get
why one may want to enforce this specific GUC at upgrade. Anyway, if
they do, I'd be curious to hear why this is required and this patch
would prevent them to do so. Actually, this could be a good reason
for making the logical slot handling during pg_upgrade an option
rather than a mandatory thing.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2023-11-02 06:10:02 Re: speed up a logical replica setup
Previous Message Michael Paquier 2023-11-02 05:48:32 Re: pg_upgrade and logical replication