From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
cc: Nathan Bossart <nathandbossart@gmail.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Fujii Masao <masao.fujii@oss.nttdata.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Add a GUC check hook to ensure summarize_wal cannot be enabled
 when wal_level is minimal
In-reply-to: 
 <CAGECzQQcLYiAdRj5xAm1G43MtpD_rm029ziqrbpqyDdxaCoEQA@mail.gmail.com>
References: <6e30082e-041b-4e31-9633-95a66de76f5d@oss.nttdata.com>
 <ZoVgXuYWbzTLXyRY@nathan>
 <802ff3d5-fdc7-4b08-9046-2e9fc5fdae0e@oss.nttdata.com>
 <CA+TgmoYPNfgAT3OubjoYSiXTb3-urOjQxT3SCEUCrRBx5g6ihA@mail.gmail.com>
 <CA+TgmoY8DnzWNK_xu4=NTYdxGBGnFucrEpOALnS0awMp-s_pKQ@mail.gmail.com>
 <7c1b48d8-0f08-4733-a4e6-d55f04581db7@oss.nttdata.com>
 <CA+TgmoansG0B8ayQGw9Ozee6Jawz=HFUACpO_4gp-+SFJBxiYw@mail.gmail.com>
 <Zo6YPuvTmRW3b1s7@nathan>
 <CAGECzQQcLYiAdRj5xAm1G43MtpD_rm029ziqrbpqyDdxaCoEQA@mail.gmail.com>
Comments: In-reply-to Jelte Fennema-Nio <postgres@jeltef.nl>
	message dated "Wed, 10 Jul 2024 16:29:14 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1744271.1720624273.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Jul 2024 11:11:13 -0400
Message-ID: <1744272.1720624273@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1744272.1720624273%40sss.pgh.pa.us>
Precedence: bulk

Jelte Fennema-Nio <postgres@jeltef.nl> writes:
> On Wed, 10 Jul 2024 at 16:18, Nathan Bossart <nathandbossart@gmail.com> =
wrote:
>> Yeah.  I initially thought this patch might be okay, at least as a stop=
gap,
>> but Jelte pointed out a case where it doesn't work, namely when you hav=
e
>> something like the following in the config file:
>> =

>> wal_level =3D 'minimal'
>> summarize_wal =3D 'true'
>> wal_level =3D 'logical'

> I think that issue can be solved fairly easily by making the guc
> check_hook always pass during postmaster startup (by e.g. checking
> pmState), and relying on the previous startup check instead during
> startup.

Please, no.  We went through a ton of permutations of that kind of
idea years ago, when it first became totally clear that cross-checks
between GUCs do not work nicely if implemented in check_hooks.
(You can find all the things we tried in the commit log, although
I don't recall exactly when.)  A counter-example for what you just
said is when a configuration file like the above is loaded after
postmaster start.

If we want to solve this, let's actually solve it, perhaps by
inventing a "consistency check" mechanism that GUC applies after
it thinks it's reached a final set of GUC values.  I'm not very
clear on how outside checking code would be able to look at the
tentative rather than active values of the variables, but that
should be solvable.

			regards, tom lane