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
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 |