[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Occupied port warning
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2005-06-30 21:28:11
Message-ID: 21887.1120166891 () sss ! pgh ! pa ! us
[Download RAW message or body]

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
[prev in list] [next in list] [prev in thread] [next in thread]