Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) 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

Reply via email to