Re: proposal: a validator for configuration files

Hi Selena,

On Mar 30, 2011, at 11:42 PM, Selena Deckelmann wrote:

> Hi!
>
> On Wed, Mar 30, 2011 at 8:40 AM, Alexey Klyukin <alexk(at)commandprompt(dot)com> wrote:
>
>
> I did a little bit of work on this, and we discussed it here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-03/msg00345.php
> http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php
>
> Probably there's a bit of bitrot in there.

Cool, I was not aware of your work in this direction. I've updated your patch
to apply to the latest HEAD, implementing Tom Lane's suggestions (attached). I
think I'll implement the other part (reporting all invalid parameters, as
opposed to only the first one) tomorrow.

>
>> The development plan consists of 2 parts.
>> The first one is to add new code that would allow running the checks in both a
>> stand-alone process, when postmaster is not running, and as a function call
>> from a backend postgres process. Initially the code would simply loads
>> configuration files, without performing any of the validation checks. The
>> second part consists of adding specific checks.
>
> Cool! Mine was only going to work if the system started up or was reloaded.

Well, I think a stand-alone check is an easy part :)
>
> As I said above, some of what you've suggested seems more like a
> non-postgres core thing.. maybe an extension? Or maybe offer the
> option to read

Well, initially I'm going to start with just a check that configuration files
are valid, and add other checks afterwards. I think it makes sense for them
to be optional.

>
> My idea was to just check that settings were *valid* not that they met
> some other, more subjective criteria.

Well, my definition of valid configuration is not only the one that server
is able to parse and load, but also to actually apply (i.e. can bind to
a listen_address or read SSL certificate files). I agree that's not always
necessary (i.e. when checking configuration on a different server than
the one it should be applied to), so we can add a flag to turn them off.

--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.