You right, of course, about that. It is 4 minutes I wasn't paying attention and thought that I have found something odd. The last packet is sent a minute and a half after the first and I miss-read that for 20 seconds.
--- On Wed, 16/7/08, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> From: Gregory Stark <stark(at)enterprisedb(dot)com>
> Subject: Re: [BUGS] Psql or test application hangs when interface is down for the DB server
> To: valiouk(at)yahoo(dot)co(dot)uk
> Cc: "ext Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "K, Niranjan (NSN - IN/Bangalore)" <niranjan(dot)k(at)nsn(dot)com>, pgsql-bugs(at)postgresql(dot)org
> Date: Wednesday, 16 July, 2008, 6:33 PM
> "Valentin Bogdanov" <valiouk(at)yahoo(dot)co(dot)uk>
> > I have noticed this as well. Blocks in poll(), timeout
> parameter -1,
> Oh good point. non-blocking sockets and poll/select let you
> control the
> timeout too.
> > meaning infinite then after 4 minutes on my system
> poll() returns 1 and
> > getsockopt() is called with SO_ERROR. SYN packets are
> tried only for the
> > default tcp timeout of 20 seconds.
> Uhm, 20 seconds would be an unreasonably low default. I
> think the RFCs mandate
> timeouts closer to the 4 minutes you describe.
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's RemoteDBA services!
> Sent via pgsql-bugs mailing list
> To make changes to your subscription:
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
In response to
pgsql-bugs by date
|Next:||From: y_takesue||Date: 2008-07-17 06:48:18|
|Previous:||From: Gregory Stark||Date: 2008-07-16 17:33:23|
|Subject: Re: Psql or test application hangs when interface is down for the DB server|