PGSTAT: bind(2): Can't assign requested address

From: "Bjoern A(dot) Zeeb" <bzeeb-lists(at)lists(dot)zabbadoz(dot)net>
To: pgsql-bugs(at)postgresql(dot)org
Subject: PGSTAT: bind(2): Can't assign requested address
Date: 2002-05-26 17:28:11
Message-ID: Pine.BSF.4.44.0205261901190.20197-100000@e0-0.zab2.int.zabbadoz.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PRIO: low

Hi,

in src/backend/postmaster/pgstat.c there is a hard coded bind to
127.0.0.1 that fails if 127.0.0.1 is not configured on loopback
interface (e.g. administrator explicitly removed this IP).
This should _not_ be the case in normal setups.

--- gmake check ---
...
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============

pg_regress: postmaster did not start
Examine ./log/postmaster.log for the reason.

kill: 97857: No such process
rm regress.o
gmake[2]: Leaving directory `/u1/local/src/postgresql/postgresql-7.2.1/src/test/regress'
gmake[1]: Leaving directory `/u1/local/src/postgresql/postgresql-7.2.1/src/test'
% cat src/test/regress/log/postmaster.log
PGSTAT: bind(2): Can't assign requested address
--- snipp ---

With postgresql-7.2.1 (and perhaps also earlier versions ?) this
prevents postmaster from starting if one does not configure
'stats_start_collector = false'.
This works as a workaround.
One may also patch the sources and recompile of course.

I have seen that there were changes in CVS already but the 127.0.0.1 is
still hard coded in there.

I discovered that after playing with some routing daemons on my test
machine and therefor had removed 127.0.0.1. OS was FreeBSD 4.5-STABLE
but that shouldn't matter.

--
Greetings

Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message pgsql-bugs 2002-05-26 18:47:45 Bug #677: Eliminating need for LD_LIBRARY_PATH during compile
Previous Message Tom Lane 2002-05-26 16:20:24 Re: bug in documentation