> * Magnus Hagander (magnus@hagander.net) wrote:
>> 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.
That's my thoughts as well, which may be off of course ;-)
>> 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? :).
Toms main argument has been that it would move the code *from* the
backend and into the *postmaster*, which is much more sensitive.
And yes, I've offered to write the code. I take this as an offer from
you to bug-test it :-)
//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