Re: killing processes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: David Kerr <dmk(at)mr-paradox(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: killing processes
Date: 2009-07-20 23:26:20
Message-ID: 29334.1248132380@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Mon, Jul 20, 2009 at 4:44 PM, David Kerr<dmk(at)mr-paradox(dot)net> wrote:
>> I'm playing around with different options for a median function. this one got out of hand
>> and was taking too long, so i wanted to kill it:
>>
>> test=# select array_median(array(select t1 from test2 order by 1));
>> ^CCancel request sent
>>
>> It just sits there, it's been trying to die for 1/2 an hour.

> What's most likely happening is that it's stuck in a tight loop that
> doesn't check for interrupts, so it just keeps on going.

Yeah, that was my first thought. What is array_median()? If it's
custom C code, you probably forgot to put CHECK_FOR_INTERRUPTS in
suitable place(s).

> You can kill -9 a process. It'll cause the postmaster to kill all
> backends and flush the buffers if I remember correctly. Yeah, not the
> ideal solution in production but on a non-prod machine it's an ok way
> to get out of these issues. And even in production, it's often much
> faster to kill -9 a single process than to wait for it to finish. I
> think there might be choices other than -9 here, but I can't recall
> them off the top of my head.

Kill -9 on the postmaster is disrecommended for a number of reasons,
but kill -9 on an individual backend is quite predictable. What it
will do is cause *all* of your open sessions to get aborted. If you
can tolerate that then do it.

If you can't tolerate that, you can try a SIGTERM, but I suspect
that if the thing is too hosed to notice a cancel (a/k/a SIGINT)
then it won't notice SIGTERM either. SIGTERM on a single backend
isn't as safe as the other options anyhow. There used to be bugs
in that code path (still ARE known bugs, if you're not running a
pretty recent PG release) and I wouldn't trust it totally.

One thing you should definitely not try is SIGQUIT. That will
kill the process all right (unless it's wedged a lot worse than
I think) but it will not do anything about cleaning up its shared
memory state, and that almost certainly will cause problems later.
Better to find a time when it's okay to use SIGKILL.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David Kerr 2009-07-20 23:33:24 Re: killing processes
Previous Message Merlin Moncure 2009-07-20 23:18:07 Re: killing processes