> 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).
I'm in agreement with this approach. Allowing a config which won't
parse properly to completely break access to a running database is
terrible. It just doesn't come across to me as being all that difficult
or complex code for pg_hba.conf.
> 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...
A little extra code in the backend is well worth fixing this foot-gun.
The concerns raised so far have been "who will write it?" and "what if
it has bugs?". Neither of these are particularly compelling arguments
when you've already offered to write and bug-test it (right, Magnus? :).
Thanks,
Stephen
No comments:
Post a Comment