From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Date: | 2008-08-03 13:11:48 |
Message-ID: | 20080803131148.GT16005@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> I think it'd be reasonable to refuse starting if the config is *known
> broken* (such as containing lines that are unparseable, or that contain
> completely invalid tokens), whereas you'd start if they just contain
> things that are "probably wrong". But picking from your previous
> examples of "more advanced checks", there are lots of cases where
> things like overlapping CIDR address ranges are perfectly valid, so I
> don't think we could even throw a warning for that - unless there's a
> separate flag to enable/disable warnings for such a thing.
Agreed. Making sure the config can parse is different from parsable but
non-sensible. It's ridiculously easy to mistakenly add a line w/ a
single character on it or something equally bad when saving a file
that's being modified by hand. That's a simple check that should be
done on re-hup and the broken config shouldn't be put in place.
I certainly agree that we should *also* have a way to just check the
config, so that can be built into init scripts and whatnot. I don't
think having one precludes having the other, and I'm pretty confident we
could find a way to not duplicate the code and have things be clean.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2008-08-03 13:16:17 | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Previous Message | Magnus Hagander | 2008-08-03 13:11:28 | Re: Parsing of pg_hba.conf and authentication inconsistencies |