Re: Occupied port warning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Occupied port warning
Date
Msg-id 21887.1120166891@sss.pgh.pa.us
Whole thread Raw
In response to Re: Occupied port warning  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Occupied port warning
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Reading the comments in StreamServerPort, it seems the only problem we 
> can't go fatal error everywhere is that on some systems the IPv4 and 
> IPv6 sockets fight each other when bind() is called.  For the other 
> failure modes, it seems that no such precautions are necessary.  In 
> particular, I think we could error out in all of the following cases:

I think you are putting *far* too much faith in the platforms that are
out there.  We fought enough kernel and libc bugs (or at least
disagreements) while we were putting in IPv6 support to make me very
wary of proposals to treat socket problems as fatal.  I would much
rather have the postmaster start and not connect to everything it
originally tried to connect to than have it refuse to play ball until
you get a new kernel version.

> - socket() failed

Definitely wrong, see archives.  EAFNOSUPPORT for example is an entirely
expected case.

> - listen() failed

Ditto, see archives.

> I think we could also error out if we cannot create at least one listen 
> socket for each entry in listen_addresses (instead of at least one 
> overall).

No; that will break cases that don't need to break.

I was willing to hold still for the limited check you just applied,
but I do not see that making it less error-tolerant than that is a
good idea at all.  It will just put obstacles in the path of newbies.

(In fact, I'm not even convinced that the limited check will survive
beta.  I think we'll be taking it out again, or at least reducing it
to a WARNING, when the complaints start coming in.  As of CVS tip,
a default postmaster configuration will refuse to start if there is
anything wrong with your "localhost" DNS setup, and we already learned
that there are way too many machines where that is true.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [PATCHES] Dbsize backend integration
Next
From: Tom Lane
Date:
Subject: Re: REL7_4_STABLE: Check failure