From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Herouth Maoz <herouth(at)unicell(dot)co(dot)il> |
Cc: | Josh Kupershmidt <schmiddy(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: stopping processes, preventing connections |
Date: | 2010-03-17 11:34:06 |
Message-ID: | 4BA0BE2E.5080000@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 17/03/2010 6:32 PM, Herouth Maoz wrote:
>
> On Mar 3, 2010, at 18:01 , Josh Kupershmidt wrote:
>
>> Though next time you see a query which doesn't respond to
>> pg_cancel_backend(), try gathering information about the query and
>> what the backend is doing; either you're doing something unusual (e.g.
>> an app is restarting the query automatically after getting canceled)
>> or perhaps you've stumbled on a bug in Postgres.
>
> Hi. A long time has passed since you made that suggestion, but today we
> stumbled again on a query that wouldn't be canceled. Not only does it
> not respond to pg_cancel_backend(), it also doesn't respond to kill
> -SIGTERM.
Interesting. If you attach gdb to the backend and run "backtrace",
what's the output?
If you strace the backend, what do you see?
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Carsten Kropf | 2010-03-17 12:04:33 | Bulkdelete and Vacuum operations on custom index |
Previous Message | zhong ming wu | 2010-03-17 11:07:09 | Re: return row from plpgsql? |