Re: fix stats_fetch_consistency value in postgresql.conf.sample

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: fix stats_fetch_consistency value in postgresql.conf.sample
Дата
Msg-id 20220530.172719.867839911471994005.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на fix stats_fetch_consistency value in postgresql.conf.sample  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: fix stats_fetch_consistency value in postgresql.conf.sample  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
At Sat, 28 May 2022 13:22:45 -0700, Andres Freund <andres@anarazel.de> 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Skipping schema changes in publication
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: ParseTzFile doesn't FreeFile on error