From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: jorsol@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is
 not set to -1
In-reply-to: 
 <CAKFQuwaH2T+Kk55SzwG5y0CtSVxyrqO-iWek54QP4YX2AWJW3w@mail.gmail.com>
References: <18979-a1b7fdbb7cd181c6@postgresql.org>
 <200807.1751815611@sss.pgh.pa.us>
 <CAKFQuwaH2T+Kk55SzwG5y0CtSVxyrqO-iWek54QP4YX2AWJW3w@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Sun, 06 Jul 2025 09:41:02 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <215700.1751824434.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 06 Jul 2025 13:53:54 -0400
Message-ID: <215701.1751824434@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/215701.1751824434%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sun, Jul 6, 2025 at 8:26=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrot=
e:
>> However, maybe instead of having check_max_slot_wal_keep_size
>> throw an error about this, we could make it just silently keep
>> the value as -1.

> Can't we just move this to postmaster.c ~ line 850 ?

max_slot_wal_keep_size is marked PGC_SIGHUP, so in principle it
could be changed after postmaster start.  So if we want a server-side
defense, I don't believe checking at postmaster start is adequate.

In practice, as long as pg_upgrade provides that -c switch, I don't
believe any other GUC source that is allowed to set a PGC_SIGHUP
GUC would override the -c switch.  So the need for any server-side
defense isn't obvious to me.

> This seems no different than wal_level and summarize_wal having a
> co-dependency such that intermediate invalid states must be allowed to
> exist so long as what the server ends up running under is valid.

I think that code doesn't do what its author hoped :-(

Anyway, I found the thread for commit 8bfb231b4 which installed
this code [1], and I'm going to go complain there.

			regards, tom lane

[1] https://www.postgresql.org/message-id/flat/20231027.115759.22068274389=
43188717.horikyota.ntt%40gmail.com