Re: fix stats_fetch_consistency value in postgresql.conf.sample

At Wed, 25 May 2022 21:25:53 -0500, Justin Pryzby <pryzby@telsasoft.com> wrote in 
> On Thu, May 26, 2022 at 11:10:18AM +0900, Kyotaro Horiguchi wrote:
> > Yeah, "boot_val" is appropreate here.  And I noticed that pg_settings
> > has the "unit" field.  I'll try using them.
> 
> I wrote this in guc.sql, which seems promising, but it needs to be rewritten in
> check_guc.pl to access postgresql.conf from the source tree.  Do you want to
> handle that ?

Yes.

> +\getenv abs_srcdir PG_ABS_SRCDIR
> +\set filename :abs_srcdir '../../../../src/backend/utils/misc/postgresql.conf.sample'
> +
> +begin;
> +CREATE TEMP TABLE sample_conf AS
> +-- SELECT m[1] AS name, trim(BOTH '''' FROM m[3]) AS sample_value
> +SELECT m[1] AS name, COALESCE(m[3], m[5]) AS sample_value
> +FROM (SELECT regexp_split_to_table(pg_read_file(:'filename'), '\n') AS ln) conf,
> +-- regexp_match(ln, '^#?([_[:alpha:]]+) (= ([^[:space:]]*)|[^ ]*$).*') AS m
> +regexp_match(ln, '^#?([_[:alpha:]]+) (= ''([^'']*)''|(= ([^[:space:]]*))|[^ ]*$).*') AS m
> +WHERE ln ~ '^#?[[:alpha:]]';
> +
> +-- test that GUCs in postgresql.conf have correct default values
> +SELECT name, tsf.cooked_value, sc.sample_value
> +FROM tab_settings_flags tsf JOIN sample_conf sc USING(name)
> +WHERE NOT not_in_sample AND tsf.cooked_value != sc.sample_value AND tsf.cooked_value||'.0' != sc.sample_value
> +ORDER BY 1;
> +rollback;
>
> It detects the original problem:
> 
>  stats_fetch_consistency     | cache                                                                    | none

Yeah, it is a straight forward outcome.

> And I think these should be updated it postgresql.conf to use the same unit as
> in current_setting().
> 
>  track_activity_query_size   | 1kB                                                                      | 1024
>  wal_buffers                 | 4MB                                                                      | -1
>  wal_receiver_timeout        | 1min                                                                     | 60s
>  wal_sender_timeout          | 1min                                                                     | 60s

I'm not sure we should do so.  Rather I'd prefer 60s than 1min here.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center