Hi, Related SO question from '13:
https://stackoverflow.com/questions/16333319/how-to-syntax-check-postgresql-config-files Peter Eisentraut answered: > There is no way to do this that is similar to apache2ctl. If you reload > the configuration files and there is a syntax error, the PostgreSQL > server will complain in the log and refuse to load the new file. > <...> > (Of course, this won't guard you against writing semantically wrong > things, but apache2ctl won't do that either.) So, at least one person in the history of the universe (besides me) has wanted a tool that does this. In addition to a simple syntax check, there's a bunch of "config wisdom" tidbits I've encountering, which is scattered through talks, commit messages, and mailing list discussion, and documentation notes (chapter 17, paragraph 12). These could be collected into a tool that: - Checks your configuration's syntax - Checks for semantically legal values ('read committed' not 'read_committed' ) - Warns of unrecognized keys ("'hot_standby' is not a valid GUC in v9.1"). - Is version-aware. - Serves as an "executable" form of past experience. - Describes the config problem in a structured way (as an expression, for example) - Includes a friendly, semi-verbose, description of the problem. - Describes ways to fix the problem, *right there*. - Is independent from server (but reuses the same parser), particularly any life-cycle commands such as restart. Users who adopt the tool will also seem more likely to contribute back coverage for any new pitfalls they fall into, which can yield feedback for developers and drive improvements in documentation. Those inclined can use the tool in their ops repo' CI. Two talk videos have been particularly valuable sources for example of configuration that can bite you: "...Lag - What's Wrong with My Slave?" (Samantha Billington, 2015) https://youtu.be/If22EwtCFKc "PostgreSQL Replication Tutorial"(Josh berkus,2015 ) https://youtu.be/GobQw9LMEaw What I've collected so far: - Quoting rules for recovery.conf and postgresql.conf are different - 'primary_conninfo' is visible to unprivileged users, so including a password is a security risk. - streaming replication + read slave should consider turning on "hot_standby_feedback". - replication_timeout < wal_receiver_status_interval is bad. - setting max_wal_senders too low so no streaming replication block backup with pg_basebackup - max_wal_senders without wal_level - recently on "weekly news": Fujii Masao pushed: Document that max_worker_processes must be high enough in standby. The setting values of some parameters including max_worker_processes must be equal to or higher than the values on the master. However, previously max_worker_processes was not listed as such parameter in the document. So this commit adds it to that list. Back-patch to 9.4 where max_worker_processes was added. http://git.postgresql.org/pg/commitdiff/1ea5ce5c5f204918b8a9fa6eaa8f3f1374aa8aec - turning on replication with default max_wal_senders =0 - FATAL: WAL archival (archive_mode=on) requires wal_level "archive", "hot_standby", or "logical" There must be more, please mention any other checks you feel should be included. Note: The server _will_ explicitly complain about the last two but a bad "wal_level" for example is only checked once the server is already down: "LOG: parameter "wal_level" cannot be changed without restarting the server" Implementation: without getting too far ahead, I feel rules should be stored as independent files in a drop directory, in some lightweight, structured format (JSON, YAML, custom textual format), with some mandatory fields (version, severity, description, solution(s)). This makes it easy for people to add new checks without making any oblique language demands (Perl isn't as popular as it used to be) Comments? Amir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
