Re: fix stats_fetch_consistency value in postgresql.conf.sample

At Thu, 26 May 2022 08:53:55 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> 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.

Yeah, "boot_val" is appropreate here. And I noticed that pg_settings
has the "unit" field. I'll try using them.

Thanks for the suggestion!

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center