X-Original-To: pgsql-performance-postgresql.org@postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id 2EB609FB2D5
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 14 Jul 2006 00:24:17 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 44345-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 14 Jul 2006 00:24:11 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from moonunit2.moonview.localnet (wsip-70-167-125-69.sd.sd.cox.net
	[70.167.125.69])
	by postgresql.org (Postfix) with ESMTP id 1A0179FB2DB
	for <pgsql-performance@postgresql.org>;
	Fri, 14 Jul 2006 00:24:11 -0300 (ADT)
Received: from [192.168.0.3] (moonunit3.moonview.localnet [192.168.0.3])
	by moonunit2.moonview.localnet (8.13.1/8.13.1) with ESMTP id
	k6E3dm72024591; Thu, 13 Jul 2006 20:39:48 -0700
Message-ID: <44B70017.6000703@modgraph-usa.com>
Date: Thu, 13 Jul 2006 19:23:19 -0700
From: "Craig A. James" <cjames@modgraph-usa.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org, sgunderson@bigfoot.com
Subject: Re: Kill a session
References: <6BCB9D8A16AC4241919521715F4D8BCEA0FAE8@algol.sollentuna.se>
	<44B51896.1000808@modgraph-usa.com> <20060712170404.GA27392@uio.no>
In-Reply-To: <20060712170404.GA27392@uio.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200607/139
X-Sequence-Number: 19999

Steinar H. Gunderson wrote:
> On Wed, Jul 12, 2006 at 08:43:18AM -0700, Craig A. James wrote:
>>> Then you killed the wrong backend...
>>> 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.
>> It turns out I was confused by this: ps(1) reports a process called 
>> "postgres", but top(1) reports a process called "postmaster", but they both 
>> have the same pid.  I guess postmaster replaces its own name in the process 
>> table when it's executing a query, and it's not really the postmaster even 
>> though top(1) calls it postmaster.
>>
>> 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 don't follow your logic here. If you do "kill -15 <pid>" of the postmaster
> doing the work, the query should be aborted without taking down the entire
> cluster. I don't see why you'd need -9 (which is a really bad idea anyhow)...

I've solved this mystery.  "kill -15" doesn't immediately kill the job -- it aborts the query, but it might take 15-30 seconds to clean up.

This confused me, because the query I was using to test took about 30 seconds, so the SIGTERM didn't seem to make a difference.  But when I used a harder query, one that would run for 5-10 minutes, SIGTERM still stopped it after 15 seconds, which isn't great but it's acceptable.  

Bottom line is that I was expecting "instant death" with SIGTERM, but instead got an agonizing, drawn out -- but safe -- death of the query.  At least that's my deduction based on experiments.  I haven't dug into the source to confirm.

Thanks everyone for your answers.  My "kill this query" feature is now acceptable.

Craig