Re: Occupied port warning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Occupied port warning
Date: 2005-06-30 21:28:11
Message-ID: 21887.1120166891@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-06-30 21:42:21 Re: REL7_4_STABLE: Check failure
Previous Message Joshua D. Drake 2005-06-30 21:27:08 Re: [PATCHES] Dbsize backend integration