Re: fix stats_fetch_consistency value in postgresql.conf.sample
От | Kyotaro Horiguchi |
---|---|
Тема | Re: fix stats_fetch_consistency value in postgresql.conf.sample |
Дата | |
Msg-id | 20220525.161207.1389849691748709887.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: fix stats_fetch_consistency value in postgresql.conf.sample (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: fix stats_fetch_consistency value in postgresql.conf.sample
|
Список | pgsql-hackers |
At Wed, 25 May 2022 15:56:23 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > The following results are not deeply confirmed yet. > > 13 apparent inconsistencies are found. These should be fixed. > > archive_command = "(disabled)" != "" The "(disabled)" is the representation of "". > bgwriter_flush_after = "64" != "0" > checkpoint_flush_after = "32" != "0" They vary according to the existence of sync_file_range(). > cluster_name = "main" != "" This is named by 003_check_guc.pl. > default_text_search_config = "pg_catalog.english" != "pg_catalog.simple" initdb decided this. > fsync = "off" != "on" > log_line_prefix = "%m [%p] %q%a " != "%m [%p] " > log_replication_commands = "on" != "off" > log_statement = "all" != "none" > max_wal_senders = "0" != "10" > restart_after_crash = "off" != "on" These are set by Cluster.pm. > wal_sync_method = "fdatasync" != "fsync" This is platform dependent. > stats_fetch_consistency = "cache" != "none" This has been fixed recently. > 11 has letter-case inconsistencies. Are these need to be fixed? > > event_source = "postgresql" != "PostgreSQL" > lc_messages = "c" != "C" > lc_monetary = "en_us.utf-8" != "C" > lc_numeric = "en_us.utf-8" != "C" > lc_time = "en_us.utf-8" != "C" > log_filename = "postgresql-%y-%m-%d_%h%m%s.log" != "postgresql-%Y-%m-%d_%H%M%S.log" > ssl_ciphers = "high:medium:+3des:!anull" != "HIGH:MEDIUM:+3DES:!aNULL" > ssl_min_protocol_version = "tlsv1.2" != "TLSv1.2" > syslog_facility = "local0" != "LOCAL0" > timezone_abbreviations = "default" != "Default" These are harmless. Since no significant inconsistency is found, there's no need to fix these either. (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. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: