Magnus Hagander <[EMAIL PROTECTED]> 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.
(The nature of CIDR notation is that there are no partial overlaps,
so it must be one of these three cases.)
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
