Re: BUG #5459: Unable to cancel query while in send()
От | Greg Stark |
---|---|
Тема | Re: BUG #5459: Unable to cancel query while in send() |
Дата | |
Msg-id | AANLkTikHjyx_EczHiaprRZVoq5tWWRAVJhnM1SJrDzfa@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5459: Unable to cancel query while in send() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Wed, May 12, 2010 at 2:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I think what you are describing is a kernel bug. =A0There's not a lot > we can do about it if the send() call hangs. =A0Considering 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. --=20 greg
В списке pgsql-bugs по дате отправления: