Re: BUG #9416: Setting up postgresql-9.1 (9.1.12-0wheezy1) Fails Configuration

As a support professional myself I understand there has to be boundaries on
what is supported by a particular project.

I can't see how the postinst script can try to code around every possible
network config failure.

On the other hand a simple message of 'Hey. I can't resolve localhost. May
I bind to the IP?' would have saved me hours and not derail the project I
was actually working on.

->>>--Patrick---Boake---->

http://www.linkedin.com/in/netscr1be

http://www.google.com/profiles/pboake

A small sum can make a huge difference.

Join us on Kiva - http://kiva.org/invitedby/NetScr1be

Kiva Team: The Beech Trees <http://www.kiva.org/team/the_beech_trees>


On Mon, Mar 3, 2014 at 6:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-03-03 16:28:21 -0500, Tom Lane wrote:
> >> Right now, you only get a failure of the pgstats subsystem, which is
> >> logged.  I don't think we can do much more than that unless you want
> >> to make it a postmaster-refuses-to-start case, which seems like not
> >> a net improvement.
>
> > I'd actually say that'd be an improvement. I've, a long time ago, spent
> > several hours debugging a case of this, it's nontrivial for a
> > beginner. And a normal PG install simply won't work properly without
> > pgstat these days, so refusing to startup seems reasonable.
>
> I still don't much like refusing to start.
>
> Perhaps we should reconsider the idea of just hardwiring "127.0.0.1" and
> the corresponding IPv6 locution into pgstats?  Or maybe better, hard-wire
> trying those if "localhost" fails to resolve.
>
>                         regards, tom lane
>