pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal
Date: Wed, 10 Jul 2024 11:11:13 -0400
Message-ID: <1744272.1720624273@sss.pgh.pa.us> (raw)
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>

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 stopgap,
>> but Jelte pointed out a case where it doesn't work, namely when you have
>> something like the following in the config file:
>> 
>> wal_level = 'minimal'
>> summarize_wal = 'true'
>> wal_level = '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





view thread (44+ messages)  latest in thread

Message-ID: <1744272.1720624273@sss.pgh.pa.us>
Permalink:  ../1744272.1720624273@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1744272.1720624273@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, postgres@jeltef.nl, nathandbossart@gmail.com, robertmhaas@gmail.com, 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: <1744272.1720624273@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox