Skip site navigation (1) Skip section navigation (2)

Re: BUG #5459: Unable to cancel query while in send()

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mason Hale <mason(at)onespot(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5459: Unable to cancel query while in send()
Date: 2010-05-31 01:58:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Wed, May 12, 2010 at 2:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think what you are describing is a kernel bug.  There's not a lot
> we can do about it if the send() call hangs.  Considering the kernel
> already knows the connection is closed (per the CLOSE_WAIT state shown
> by netstat) the send() should return failure immediately, and it's not
> doing so.

For what it's worth CLOSE_WAIT means the remote end has sent a FIN but
the local end hasn't closed the connection. TCP connections can live
in this half-open state (or its dual) for a while with one direction
closed but the other direction still open. So send() isn't necessarily
going to return an error or anything, it will expect the remote end to
keep receiving data or send an RST if it's actually gone away.

I'm not sure I have a clear idea of the exact scenario from the
description provided. It seems there should be two connections in psql
-> ssh -> postgres and two endpoints for each connection, so I'm not
sure which connections were in CLOSE_WAIT and FIN_WAIT2 and which two
we're still missing.

I'm not sure how ssh behaves when one side closes a connection. It
might not reproduce the half-open connection on the either side
preventing psql/postgres from responding appropriately. I'm not even
sure it's possible for it to do so reliably.


In response to

pgsql-bugs by date

Next:From: Jakub BogaczDate: 2010-05-31 08:01:24
Subject: BUG #5485: Microsoft VC++ exception during postgres instalation
Previous:From: Matthew NourseDate: 2010-05-30 23:07:53
Subject: Re: BUG #5477: CREATE DOMAIN NOT NULL constraints not always enforced for INSERT with subquery

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group