Re: canceling query
От | Magnus Hagander |
---|---|
Тема | Re: canceling query |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE34B7A0@algol.sollentuna.se обсуждение исходный текст |
Ответ на | canceling query ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Список | 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
В списке pgsql-hackers-win32 по дате отправления: