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
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 |