Re: Kill a session

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