> Robert Treat <xzilla@users.sourceforge.net> writes:
>> Certainly there isn't any reason to allow a reload of a file that is just
>> going to break things when the first connection happens. For that matter,
>> why would we ever not want to parse it at HUP time rather than connect time?
>
> Two or three reasons why not were already mentioned upthread, but for
> the stubborn, here's another one: are you volunteering to write the code
> that backs out the config-file reload after the checks have determined
> it was bad? Given the amount of pain we suffered trying to make GUC do
> something similar, any sane person would run screaming from the
> prospect.
For pg_hba.conf, I don't see that as a very big problem, really. It
doesn't (and shouldn't) modify any "external" variables, so it should be
as simple as parsing the new file into a completely separate
list-of-structs and only if it's all correct switch the main pointer
(and free the old struct).
Yes, I still think we should do the "simple parsing" step at HUP time.
That doesn't mean that it wouldn't be a good idea to have one of these
check-config options that can look for conflicting options *as well*, of
course. But I'm getting the feeling I'm on the losing side of the debate
here...
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment