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

The following bug has been logged on the website:

Bug reference:      9416
Logged by:          Patrick Boake
Email address:      pboake@gmail.com
PostgreSQL version: 9.1.12
Operating system:   Debian
Description:

I have seen multiple reports of this but no solutions beyond 'whitelisting'
the package in update-rc.d.

I don't know how to do that or why it's necessary.

No other problems with system.


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.
dpkg: error processing postgresql-9.1 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 postgresql-9.1
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

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>



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

> 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
>

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

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

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

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

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

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

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
>

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. +