From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: killing pg_dump leaves backend process |
Date: | 2013-08-11 02:10:17 |
Message-ID: | 20130811021017.GA483991@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 10, 2013 at 12:26:43PM +0100, Greg Stark wrote:
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Any other client would behave the same
> > if it were killed while waiting for some backend query. So the right
> > fix would involve figuring out a way for the backend to kill itself
> > if the client connection goes away while it's waiting.
>
> Well I'm not sure. Maybe every other client should also issue a query
> cancel and close the connection if it gets killed. libpq could offer a
> function specifically for programs to call from atexit(), signal
> handlers, or exception handlers (yes, that might be a bit tricky).
>
> But I do see a convincing argument for doing something in the server.
> Namely that if you kill -9 the client surely the server should still
> detect that the connection has gone away immediately.
I agree that both efforts have value. A client-side change can't replace the
server-side change, and tightening the client side will be more of a neatness
measure once the server-side mechanism is in place.
> The problem is that I don't know of any way to detect eof on a socket
> other than trying to read from it (or calling poll or select). So the
> server would have to periodically poll the client even when it's not
> expecting any data. The inefficiency is annoying enough and it still
> won't detect the eof immediately.
Yes, I think that is the way to do it. The check interval could default to
something like 90s, high enough to make the cost disappear into the noise and
yet a dramatic improvement over the current "no fixed time limit".
I bet the utils/timeout.h infrastructure added in 9.3 will make this at least
60% easier to implement than it would have been before.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2013-08-11 02:24:35 | Re: killing pg_dump leaves backend process |
Previous Message | Bruce Momjian | 2013-08-10 21:04:42 | Re: Postgres 9.3 beta log |