Tom Lane wrote: > Robert Treat <[EMAIL PROTECTED]> 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
