Alexey Klyukin <al...@commandprompt.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
