From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com> |
Subject: | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Date: | 2008-08-03 08:29:22 |
Message-ID: | 48956C62.4020505@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-08-03 08:36:56 | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Previous Message | daveg | 2008-08-03 07:44:03 | Re: Mini improvement: statement_cost_limit |