From: Craig A. James <cjames@modgraph-usa.com>
To: pgsql-performance@postgresql.org
To: sgunderson@bigfoot.com
Subject: Re: Kill a session
Date: Thu, 13 Jul 2006 19:23:19 -0700
Message-ID: <44B70017.6000703@modgraph-usa.com> (raw)
In-Reply-To: <20060712170404.GA27392@uio.no>
References: <6BCB9D8A16AC4241919521715F4D8BCEA0FAE8@algol.sollentuna.se>
<44B51896.1000808@modgraph-usa.com>
<20060712170404.GA27392@uio.no>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: cjames@modgraph-usa.com, sgunderson@bigfoot.com
Subject: Re: Kill a session
In-Reply-To: <44B70017.6000703@modgraph-usa.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox