public inbox for [email protected]  

help / color / mirror / Atom feed

From: Kyotaro Horiguchi <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: fix stats_fetch_consistency value in postgresql.conf.sample
Date: Mon, 30 May 2022 17:27:19 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

At Sat, 28 May 2022 13:22:45 -0700, Andres Freund <[email protected]> wrote in 
> Hi,
> 
> On 2022-05-26 16:27:53 +0900, Kyotaro Horiguchi wrote:
> > It could be in SQL, but *I* prefer to use perl for this, since it
> > allows me to write a bit complex things (than simple string
> > comparison) simpler.
> 
> I wonder if we shouldn't just expose a C function to do this, rather than
> having a separate implementation in a tap test.

It was annoying that I needed to copy the unit-conversion stuff.  I
did that in the attached.  parse_val() and check_val() and the duped
data is removed.

> > +# parameter names that cannot get consistency check performed
> > +my @ignored_parameters =
> 
> I think most of these we could ignore by relying on source <> 'override'
> instead of listing them?
> 
> 
> > +# parameter names that requires case-insensitive check
> > +my @case_insensitive_params =
> > +  ('ssl_ciphers',
> > +   'log_filename',
> > +   'event_source',
> > +   'log_timezone',
> > +   'timezone',
> > +   'lc_monetary',
> > +   'lc_numeric',
> > +   'lc_time');
> 
> Why do these differ by case?

Mmm. It just came out of a thinko. I somehow believed that the script
down-cases only the parameter names among the values from
pg_settings. I felt that something's strange while on it,
though.. After fixing it, there are only the following values that
differ only in letter cases. In passing I changed "bool" and "enum"
are case-sensitive, too.

name              conf          bootval
client_encoding: "sql_ascii"  "SQL_ASCII"
datestyle      : "iso, mdy"   "ISO, MDY"
syslog_facility: "LOCAL0"     "local0"

It seems to me that the bootval is right for all variables.


I added a testing-aid function pg_normalize_config_option(name,value)
so the consistency check can be performed like this.

SELECT f.n, f.v, s.boot_val
    FROM (VALUES ('work_mem','4MB'),...) f(n,v)
    JOIN pg_settings s ON s.name = f.n '.
    WHERE pg_normalize_config_value(f.n, f.v) <> '.
          pg_normalize_config_value(f.n, s.boot_val)';

There're some concerns on the function.

- _ShowConfig() returns archive_command as "(disabled)" regardless of
  its value.  The test passes accidentally for the variable...

- _ShowConfig() errors out for "timezone_abbreviations" and "" since
  the check function tries to open the timezone file. (It is excluded
  from the test.)

I don't want to create a copy of the function only for this purpose.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

view thread (42+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: fix stats_fetch_consistency value in postgresql.conf.sample
  In-Reply-To: <[email protected]>

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

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