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