Re: REVIEW proposal: a validator for configuration files
От | Tom Lane |
---|---|
Тема | Re: REVIEW proposal: a validator for configuration files |
Дата | |
Msg-id | 794.1317589074@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: REVIEW proposal: a validator for configuration files (Alexey Klyukin <alexk@commandprompt.com>) |
Список | pgsql-hackers |
Alexey Klyukin <alexk@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
В списке pgsql-hackers по дате отправления: