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
