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
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 |