Message-ID: <44B6FEAA.7070708@modgraph-usa.com>
Date: Thu, 13 Jul 2006 19:17:14 -0700
From: "Craig A. James" <cjames@modgraph-usa.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Mark Kirkwood <markir@paradise.net.nz>
CC: Magnus Hagander <mha@sollentuna.net>, pgsql-performance@postgresql.org
Subject: Re: Kill a session
References: <6BCB9D8A16AC4241919521715F4D8BCEA0FAE8@algol.sollentuna.se>
	<44B51896.1000808@modgraph-usa.com>
	<44B6F3BF.1000602@paradise.net.nz>
In-Reply-To: <44B6F3BF.1000602@paradise.net.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for your reply, Mark:
>> 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?
>
> ... if you actually want to disconnect a backend 
> process then there is nothing to let you do this remotely. I recently 
> did a patch for Bizgres that just implements the 
> pg_terminate_backend(pid) function (currently #ifdef'ed out of the 
> codebase) as a contrib so it can be easily installed. See 
> http://pgfoundry.org/pipermail/bizgres-general/2006-May/000484.html

This answers my question.  I've finally got a statement in concrete terms, Postgres has no way to kill a backend process via an SQL statement.  "If Mark had to resort to this, then there is no other way."

> If you want to try it out, please read the README (it discusses possible 
> dangers associated with sending SIGTERM to backends). And I would 
> certainly be interested in hearing what level of success (or otherwise) 
> you have with it!

Thanks, but I've already implemented my own, which is essentially identical in concept to yours, but simpler in the sense of being even less safe than yours -- I just let anyone send the signal, since I have no users other than my own app.  I'll keep my version since it's embedded in my own plug-in.  That way I won't have to keep remembering to modify the Postgres code when I upgrade.  I like to keep Postgres "stock".

Craig