Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files - Mailing list pgsql-hackers

On 10/09/2015 09:55 PM, Robert Haas wrote:
> On Thu, Oct 8, 2015 at 9:06 AM, Amir Rohan <amir.rohan@zoho.com> wrote:
>> On 10/08/2015 02:38 PM, Tom Lane wrote:
>>> Amir Rohan <amir.rohan@zoho.com> writes:
>>>> Comments?
>>>
>>> ISTM that all of the "functional" parts of this are superseded by
>>> pg_file_settings;
>>
>> To use the new pg_file_settings view you need:
>> 1( 9.5+
>> 2( a running server
>>
>> The feature is describes as follows in a97e0c3354ace5d74
>>
>>> The information returned includes the configuration file name, line
>>> number in that file, sequence number indicating when the parameter is
>>> loaded )useful to see if it is later masked by another definition of
>>> the same parameter(, parameter name, and what it is set to at that
>>> point. This information is updated on reload of the server.
>>
>> None of which has much overlap in purpose with what I was suggesting, so
>> I don't see why you think it actually makes it redundant.
> 
> I think Tom's point is that if you want to see whether the file
> reloads without errors, you can use this view for that.  That would
> catch stuff like wal_level=lgocial and
> default_transaction_isolation='read_committed'.
> 


It does catch bad syntax, but in most cases all you get is
"The setting could not be applied".  that's not great for enums
or a float instead of an int. I guess a future version will fix that
(or not). You need a running server to run a check. You need to monkey
with said server's configuration in place to run a check. You must be on
9.5+. The checking mechanism isn't extensible. Certainly not as easily
as dropping a new rule file somewhere. It doesn't check (AFAICT) for bad
combinations of values, for example it will tell you that you can't
change `wal_archive` without restart (without showing source location
btw, bug?), but not that you better set `wal_level` *before* you
restart.  It doesn't do any semantic checks. It won't warn you
about things that are not actually an error, just a bad idea.

Forgive me if any of the above betrays an ignorance of some of
pg_file_settings's finer points. I have only read the documentation and
tried it in a shell.

There was also concern about the prohibitive maintenance burden such a
tool would impose. ISTM all you actually need is a JSON file generated
from the output of `select * from pg_settings` to make the really
tedious bit completely automatic. The semantic checks are by their
nature "best effort", and it's my impression (and only that) that
they are more stable, in the sense that bad ideas remain so.

That's why I disagree with tom's suggestion that pg_file_settings
obviates the need for the tool I proposed. Which isn't at all to
say it doesn't solve another very well.

Amir