Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: canceling query


  • 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: Mon, 19 Apr 2004 16:58:16 +0200
  • Message-id: <6BCB9D8A16AC4241919521715F4D8BCE34B7A0(at)algol(dot)sollentuna(dot)se>

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



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group