Re: Full socket send buffer prevents cancel, timeout

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Full socket send buffer prevents cancel, timeout
Date: 2008-10-26 02:31:31
Message-ID: 20081026023130.GA56881@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 25, 2008 at 12:36:24PM -0400, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)org> writes:
> > If the write is interrupted by a timeout or cancel, can anything
> > be done here or elsewhere to abort the statement and release its
> > locks?
>
> The best thing would really be to kill the client.

Unfortunately the people running the database don't have control
over the client. They'd like to kill the connection at the database
end but we haven't yet found a reliable way to do that short of an
immediate shutdown, which interrupts service and can lead to a long
recovery. Are we missing any other possibilities?

> The backend can't take it upon itself to interrupt the send, because
> that would result in loss of protocol message sync, and without
> knowing how many bytes got sent there's really no way to recover.
> The only escape from the backend side would be to abort the session ---
> and even that's a bit problematic since we'd probably try to issue an
> error message somewhere on the way out, which isn't going to work
> either if the send buffer is full.

Yeah, I've already explained those difficulties. I was hoping that
discussion might generate ideas on how to deal with them.

--
Michael Fuhr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2008-10-26 03:29:49 BufferAccessStrategy for bulk insert
Previous Message Tom Lane 2008-10-26 01:55:47 Re: Regression in IN( field, field, field ) performance