Re: fix stats_fetch_consistency value in postgresql.conf.sample

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: andres(at)anarazel(dot)de, nathandbossart(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: fix stats_fetch_consistency value in postgresql.conf.sample
Date: 2022-05-25 23:53:55
Message-ID: Yo7Bk0tPTyKvIduo@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 25, 2022 at 04:12:07PM +0900, Kyotaro Horiguchi wrote:
> (sigh..) As the result, no need to fix in this area for now, and I
> don't think there's any generic and reliable way to detect
> inconsistencies of guc variable definitions.

Hmm. Making the automation test painless in terms of maintenance
consists in making it require zero manual filtering in the list of
GUCs involved, while still being useful in what it can detect. The
units involved in a GUC make the checks between postgresql.conf.sample
and pg_settings.boot_value annoying because they would require extra
calculations depending on the unit with a logic maintained in the
test.

I may be missing something obvious, of course, but it seems to me that
as long as you fetch the values from postgresql.conf.sample and
cross-check them with pg_settings.boot_value for GUCs that do not have
units, the maintenance would be painless, while still being useful (it
would cover the case of enums, for one). The values need to be
lower-cased for consistency, similarly to the GUC names.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-05-26 00:33:47 Re: Authorizing select count()
Previous Message Zheng Li 2022-05-25 20:42:29 Re: logical decoding and replication of sequences