Re: What is happening on buildfarm member baiji?

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

In response to

Browse pgsql-hackers by date

  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