From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Mason Hale" <mason(at)onespot(dot)com> |
Subject: | Re: BUG #5459: Unable to cancel query while in send() |
Date: | 2010-05-12 08:30:52 |
Message-ID: | 201005121030.53490.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On Wednesday 12 May 2010 03:44:16 Tom Lane wrote:
> "Mason Hale" <mason(at)onespot(dot)com> writes:
> > ISSUE: unable to cancel queries using pg_cancel_backend(), that are in
> > send() function call, waiting on client receipt of data.
> 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.
I can reproduce the issue though when the connection just is very, very slow
(high packet loss). Uppon receiving a signal the send returns with EINTR uppon
which point I think a check for interrupts might be placed.
> There might be some TCP-level incompatibility involved between the
> database and gateway server TCP stacks, since the combination of the
> FIN_WAIT2 and CLOSE_WAIT states really ought not persist very long;
> but I'm not a network hacker so I'm a bit out of my depth in diagnosing
> that aspect of it.
There is a userland implementation (ssh) involved, so that does sound likely.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Russell Smith | 2010-05-12 09:47:15 | Re: PostgreSQL 8.4 - dumping database connection privileges |
Previous Message | Bryan Henderson | 2010-05-12 01:55:17 | Re: bool: symbol name collision |