> There have been dozens, perhaps hundreds, of entries in the > pg-admin, pg-general, and pg-performance lists regarding > killing a session, but as far as I can tell, there is no > Postgres solution. Did I miss something? > > This raises the question: Why doesn't Postgres have a "kill > session" command that works? Oracle has it, and it's > invaluable; there is no substitute. Various writers to these > PG lists have raised the question repeatedly. Is it just a > matter that nobody has had the time to do it (which I > respect!), or is there a reason why the Postgres team decided > a "kill session" is a bad idea? [snip] 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. > But in spite earlier posting in these forums that say the > killing the backend was the way to go, this doesn't really > work. First, even though the "postgres" backend job is > properly killed, a "postmaster" job keeps running at 99% CPU, > which is pretty useless. Killing the client's backend didn't > kill the process actually doing the work! Then you killed the wrong backend... > Second, the "KILLING SESSION" message to stderr is only > printed in the PG log file sporadically. This confuses me, > since the "KILLING SESSION" is printed by a *different* > process than the one being killed, so it shouldn't be > affected. So what happens to fprintf()'s output? Most of > the time, I just get "unexpected EOF on client connection" in > the log which is presumably the postmaster complaining that > the postgres child process died. No, that's the postgres chlid process complaining that your client (CGI?) died without sending a close message. > I know the kill_session() is working because it returns > "true", and the job is in fact killed. But the query keeps > running in postmaster (or is it something else, like a > rollback?), and the stderr output disappears. No queries run in postmaster. They all run in postgres backends. The postmaster does very little actual work, other than keeping track of everybody else. //Magnus
