From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: canceling query |
Date: | 2004-04-19 14:58:16 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE34B7A0@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
> > It should die once it tries to send data down the TCP connection,
> > though. Since the other end of the socket is gone. Do you
> know if your
> > query gets that for, or is it still executing?
>
> Still executing. CPU load high, and pg_stat_activity reports
> that particular query running on that particular backend.
Ok. If you have the time/CPU to spare, it would be intersting to see if
it goes down once it starts sending results to the frontend (which is
gone).
> > There really should be no need to bring down the entire postmaster.
>
> Yes...Isn't it possible to set up your app so that it can't
> be brought down by the task manager? (IIRC this may only be
> possible with
> services) Of course, this is not a good idea until there is
> a proper cancel.
No, this can't be done.
A GUI program can be set to ignore close requests, but you cannot
prevent it from being killed from the "processes" tab. Unless you put in
a kernel driver there to prevent it, and that's not going to happen :-
> My personal design philosophy is to try and keep normal query
> execution time < 1 sec, so I'm not overly concerned about
> this. I'm just beating on the postmaster to see what can
> come up with.
Oh yes, this kind of testing is defintly what we need now.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2004-04-19 15:06:47 | Re: canceling query |
Previous Message | Merlin Moncure | 2004-04-19 14:57:21 | Re: canceling query |