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