From: | Andrew - Supernews <andrew+nonews(at)supernews(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: What is happening on buildfarm member baiji? |
Date: | 2007-05-14 17:26:05 |
Message-ID: | slrnf4h6td.1j7n.andrew+nonews@atlantis.supernews.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2007-05-14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
>> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [070514 10:24]:
>>> This is not a behavior required by the TCP spec AFAICS. Also, in a
>>> quick test neither Linux nor HPUX appear to need SO_REUSEADDR --- on
>>> both, I can restart the postmaster immediately without it.
>
>> Did you have an active connection before restarting?
>> In HylaFAX, we had the same situation and went to using SO_REUSEADDR:
>> http://bugs.hylafax.org/show_bug.cgi?id=217
>
> Um, you're right, I hadn't done the test properly. If I have an open
> psql session across TCP and do pg_ctl stop -m fast, then I can't
> start a new postmaster until the socket goes out of CLOSE_WAIT state.
> Which, if I just leave the psql session sit there, seems to mean
> "indefinitely" ... so it's even worse than just a TCP timeout.
SO_REUSEADDR is required in all cases where you bind a listening socket
to a specific port number. There are no exceptions to this rule.
This is an artifact of the Berkeley Sockets interface design, not something
inherent in the TCP spec. It arises because the sockets interface separates
the bind() and listen()/connect() calls; if you replace bind/listen/connect
with a single system call, then SO_REUSEADDR becomes unnecessary. (The
behaviour of bind() needs to be different depending on whether it will be
followed by listen() or connect(); this was not well understood by the
original designers of the API, hence the use of SO_REUSEADDR as a klugy
way of saying "I'm going to use listen() on this socket after the bind".)
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-05-14 17:26:42 | Re: Concurrent psql patch |
Previous Message | Jim C. Nasby | 2007-05-14 16:55:07 | Re: Concurrent psql patch |