Re: A recent message added to pg_upgade

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Peter Smith <smithpb2250@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, bharath.rupireddyforpostgres@gmail.com, amit.kapila16@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Date: 2023-11-02T06:02:26Z
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@gmail.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

Commits

  1. Fix the handling of two GUCs during upgrade.

  2. Rework how logirep launchers are stopped during pg_upgrade

  3. Prohibit max_slot_wal_keep_size to value other than -1 during upgrade.

  4. Prevent startup of logical replication launcher during pg_upgrade

  5. Migrate logical slots to the new node during an upgrade.