Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Seems a lot better to me to just train people to run the check-config
>>> code by hand before pulling the trigger to load the settings for real.
>
>> 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.
>
> There are cases that are sane, and there are cases that are not.
> You've got three possibilities:
>
> * two lines referencing the exact same address range (and other
> selectors such as user/database). Definitely a mistake, because
> the second one is unreachable.
>
> * two lines where the second's address range is a subset of the
> first (and other stuff is the same). Likewise a mistake.
>
> * two lines where the first's address range is a subset of the
> second's. This one is the only sane one.
Yeah, certainly. But a very common one at that.
> (The nature of CIDR notation is that there are no partial overlaps,
> so it must be one of these three cases.)
Right.
> We have in fact seen complaints from people who apparently missed
> the fact that pg_hba.conf entries are order-sensitive, so I think
> a test like this would be worth making. But it shouldn't be done
> by the postmaster.
Agreed. Postmaster should verify things only to the point that it's a
valid CIDR mask (say that the IP is actually numeric and not
1.2.foo.3/32). Any further context analysis does not belong there.
Should I read this as you warming up slightly to the idea of having the
postmaster do that? ;-)
//Magnus
