> > I beleive the function to kill a backend is actually in the 
> codebase, 
> > it's just commented out because it's considered dangerous. 
> There are 
> > some possible issues (see -hackers archives) about sending SIGTERM 
> > without actually shutting down the whole cluster.
> > 
> > Doing the client-side function to call is the easy part.
> > 
> > In many cases you just need to cancel a query, in which 
> case you can 
> > use
> > pg_cancel_backend() for exmaple. If you need to actually 
> kill it, your 
> > only supported way is to restart postgresql.
> 
> In other words, are you confirming that there is no way to 
> kill a query from another process, other than shutting down 
> the database?  My understanding of the documentation tells me 
> I can't use cancel, because the process doing the killing 
> isn't the original process.

You can't kill another backend, no.
You can *cancel* a query on it and return it to idle state. See
http://www.postgresql.org/docs/8.1/interactive/functions-admin.html,
pg_cancel_backend().


> So "kill -15 <pid>" is NOT killing the process -- to kill the 
> process, I have to use signal 9.  But if I do that, ALL 
> queries in progress are aborted.  I might as well shut down 
> and restart the database, which is an unacceptable solution 
> for a web site.
> 
> I'm back to my original question: How do you kill a runaway 
> query without bringing down the whole database?  Is there 
> really no answer to this?

Runaway queries can be killed with pg_cancel_backend(), or from the
commandline using kill -INT <pid>. The backend will still be around, but
it will have cancelled the query.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to