Re: Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

On Fri, Oct 28, 2011 at 3:11 AM, Robert Young <yayooo(at)gmail(dot)com> wrote:
> I am just wondering, why "localhost" entry in /etc/hosts is editable
> and why 127.0.0.1 not fixed with loopback interface?
> should you agree with that we should submit a patch to kernel to
> resolve "localhost" to 127.0.0.1 statically need no entry in
> /etc/hosts and loopback interface bind to 127.0.0.1 not changeable?

You're attacking a straw man. Removing /etc/hosts altogether is also
not recommended; maybe you should submit a kernel patch to make it
impossible to unlink it. You probably shouldn't remove /bin/ls
either, so better include that in the patch, too. And on and on. It
isn't possible for PostgreSQL or any other tool to protect itself
against every stupid configuration someone might create, and we
shouldn't try. root can bypass all permissions checks; that means
root can do really, incredibly dumb things. In the PostgreSQL world,
the database superuser can do similarly dumb things, like "DELETE FROM
pg_proc".

The question here is not whether it should be impossible to edit
/etc/hosts; it's whether it's ever a good idea to set up the
configuration you're describing. If there is a legitimate use-case
for that configuration, then we ought to support it, ideally without
adding a new GUC but perhaps doing so if there is no reasonable
alternative. But if the configuration that you're proposing is
something that no one should ever do in the first place, then it makes
no sense for us to spend time worrying about how to make it work. Tom
is arguing that it falls into the latter category. I am not sure that
he's right, but if you want to argue for this patch, you're argument
shouldn't be that more configuration knobs are better (which most
PostgreSQL project members, inculding me, do not believe, because it
means more code to maintain and frequently confuses users to no
benefit) but rather that this particular configuration option is
needed to support some sensible use case that can't be supported any
other way.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company