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