Re: REVIEW proposal: a validator for configuration files

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexey Klyukin <alexk(at)commandprompt(dot)com>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REVIEW proposal: a validator for configuration files
Date: 2011-10-02 20:57:54
Message-ID: 794.1317589074@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alexey Klyukin <alexk(at)commandprompt(dot)com> writes:
> Attached is v5. It should fix both problems you've experienced with v4.

I've applied this patch after some additional hacking.

> One problem I'm not sure how to address is the fact that we require 2
> calls of set_config_option for each option, one to verify the new
> value and another to actually apply it. Normally, this function
> returns true for a valid value and false if it is unable to set the
> new value for whatever reason (either the value is invalid, or the
> value cannot be changed in the context of the caller). However,
> calling it once per value in the 'apply' mode during reload produces
> false for every unchanged value that can only be changed during
> startup (i.e. shared_buffers, or max_connections).

I thought that the most reasonable solution here was to extend
set_config_option to provide a three-valued result: applied, error,
or not-applied-for-some-non-error-reason. So I did that, and then
ripped out the first set of calls to set_config_option. That should
make things a bit faster, as well as eliminating a set of corner cases
where the "checking" call succeeds but then the real apply step fails
anyway.

I also got rid of the changes to ParseConfigFile's API. I thought those
were messy and unnecessary, because there's no good reason not to define
the parse-error limit as being so many errors per file. It's really
only there to prevent the "config file contains War and Peace" syndrome
anyway.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-02 21:05:38 Should we get rid of custom_variable_classes altogether?
Previous Message Dimitri Fontaine 2011-10-02 20:08:14 Re: [v9.2] DROP statement reworks