Re: Parsing of pg_hba.conf and authentication inconsistencies
От | Magnus Hagander |
---|---|
Тема | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Дата | |
Msg-id | 48956C62.4020505@hagander.net обсуждение исходный текст |
Ответ на | Re: Parsing of pg_hba.conf and authentication inconsistencies (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Parsing of pg_hba.conf and authentication
inconsistencies
|
Список | pgsql-hackers |
Tom Lane wrote: > Robert Treat <xzilla@users.sourceforge.net> 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
В списке pgsql-hackers по дате отправления: