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

pboake@gmail.com writes:

apt-get upgrade returns;

Setting up postgresql-9.1 (9.1.12-0wheezy1) ...
[....] Starting PostgreSQL 9.1 database server: main[....] The PostgreSQL
server failed to start. Please check the log output: 2014-03-02 22:13:28 EST
LOG: could not bind IPv4 socket: Cannot assign requested address 2014-03-02
22:13:28 EST HINT: Is another postmaster already running on port 5432? If
not, wait a few seconds and retry. 2014-03-02 22:13:28 EST LOG: could not
bind IPv6 socket: Cannot assign requested address 2014-03-02 22:13:28 EST
HINT: Is another postmaster already running on port 5432? If not, wait a few
seconds and retry. 2014-03-02 22:1[FAILEST WARNING: could not create listen
socket for "localhost" 2014-03-02 22:13:28 EST FATAL: could not create any
TCP/IP sockets ... failed!
failed!
invoke-rc.d: initscript postgresql, action "start" failed.

What that looks like is that the package's upgrade script forgot to stop
the old postmaster version before trying to start the new one; or perhaps
slightly more likely, failed to wait for the old postmaster to finish
stopping.

Either way, that would be a bug in the packaging, which you should take
up with the Debian package maintainer, not with the upstream project.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

You are somewhat correct Tom,

I got it to work after finding out my system was unable to resolve
localhost.

Once it was able to do that the upgrade went through.

I'm off to find the package maintainer who assumes localhost resolves
successfully.

There should at least be a better error message.

Close this bug if you haven't already,

--PB--

->>>--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&gt;

On Mon, Mar 3, 2014 at 10:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Patrick Boake escribi�:

You are somewhat correct Tom,

I got it to work after finding out my system was unable to resolve
localhost.

Once it was able to do that the upgrade went through.

I'm off to find the package maintainer who assumes localhost resolves
successfully.

Postgres itself assumes localhost resolves. Why would you make that
fail?

Since we have seen this kind of failure reported many times, I wonder if
it'd make sense to check specifically for inability to resolve localhost,
if only to save troubleshooters' time.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Since we have seen this kind of failure reported many times, I wonder if
it'd make sense to check specifically for inability to resolve localhost,
if only to save troubleshooters' time.

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.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 2014-03-03 16:28:21 -0500, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Since we have seen this kind of failure reported many times, I wonder if
it'd make sense to check specifically for inability to resolve localhost,
if only to save troubleshooters' time.

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.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 3.3.2014 22:31, Andres Freund wrote:

On 2014-03-03 16:28:21 -0500, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Since we have seen this kind of failure reported many times, I
wonder if it'd make sense to check specifically for inability to
resolve localhost, if only to save troubleshooters' time.

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'm not sure whether that'd be an improvement or not - whether it's
better to log the issue but start the database (and face the issues
later - maybe weeks or months, when the message we logged is lost). Or
fail promptly and force them to fix the actual issue.

A failure to start pgstats subsystem however means

(a) no stats collector process, and thus no autovacuum/autoanalyze

(b) no relpages/reltuples in pg_class or any other statistics (unless
running analyze explicitly, which people don't due as they rely on
autovacuum/autoanalyze)

(c) no transaction wraparound handling (again, no autovacuum running)

So I'd probably vote for failing right away, and mentioning a working
localhost resolution as a requirement in the docs.

If that's unacceptable, maybe it'd be a good idea to modify the
functions backing pg_stat_* views to fail with ERROR, i.e.

if (pgStatSock == PGINVALID_SOCKET)
elog(ERROR, "statistics collector is not running");

because right now it's going to wait for 'pgstat wait timeout'.

regards
Tomas

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Tom Lane escribi�:

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.

That (hard-wiring when resolution fails) seems reasonable.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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&gt;

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

On Tue, Mar 4, 2014 at 11:29:19AM -0300, Alvaro Herrera wrote:

Tom Lane escribi�:

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.

That (hard-wiring when resolution fails) seems reasonable.

Is this something we should put on the TODO?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs