From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
        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: <ZpBDspLe_AoC274c@nathan>
References: <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>
 <1744272.1720624273@sss.pgh.pa.us> <Zo7V5Ry9_sDpPmXo@nathan>
 <ZpBDspLe_AoC274c@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Thu, 11 Jul 2024 15:42:26 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2217358.1720734419.1@sss.pgh.pa.us>
Date: Thu, 11 Jul 2024 17:46:59 -0400
Message-ID: <2217359.1720734419@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2217359.1720734419%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Jul 10, 2024 at 01:41:41PM -0500, Nathan Bossart wrote:
>> On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote:
>>> 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.

>> Do you remember the general timeframe or any of the GUCs involved?  I spent
>> some time searching through the commit log and mailing lists, but I've thus
>> far only found allusions to past bad experiences with such hooks.

> Could it be the effective_cache_size work from 2013-2014?

Yeah, that's what I was remembering.  It looks like my memory was
slightly faulty, in that what ee1e5662d tried to do was make the
default value of one GUC depend on the actual value of another one,
not implement a consistency check per se.  But the underlying problem
is the same: a check_hook can't assume it is seeing the appropriate
value of some other GUC, since a change of that one may be pending.

			regards, tom lane