Re: pg_cancel_backend() does not work with buzz queries - Mailing list pgsql-general

From Magnus Hagander
Subject Re: pg_cancel_backend() does not work with buzz queries
Date
Msg-id 20071003105723.GD22596@svr2.hagander.net
Whole thread Raw
In response to Re: pg_cancel_backend() does not work with buzz queries  (Richard Huxton <dev@archonet.com>)
Responses Re: pg_cancel_backend() does not work with buzz queries  ("Sergey Konoplev" <gray.ru@gmail.com>)
Re: pg_cancel_backend() does not work with buzz queries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Wed, Oct 03, 2007 at 11:18:32AM +0100, Richard Huxton wrote:
> Don't forget to cc: the list.
> Try not to top-post replies, it's easier to read if you reply below the
> text you're replying to.
>
> Sergey Konoplev wrote:
> >>1. Is it always the same query?
> >>2. Does the client still think it's connected?
> >>3. Is that query using up CPU, or just idling?
> >>4. Anything odd in pg_locks for the problem pid?
>
> >1. No it isn't. I have few functions (plpgsql, plpython) that cause
> >such situations more often than another but they are called more often
> >also.
>
> OK, so there's no real pattern. That would suggest it's not a particular
> query-plan that's got something wrong.
>
> Do you always get this problem inside a function?

Does pl/python listen to SIGINT during execution of functions? If not,
that'd be an explanation - if it's stuck inside a pl/python function...

AFAIK, pl/pgsql does listen for SIGINT during execution, but I don't nkow
abuot plpython.

> 4. You have to cancel the query from the command-line using "kill -9
> <backend-pid>"

That's not cancel, that's taking a sledgehammer to your server :(

//Magnus

pgsql-general by date:

Previous
From: Diego Gil
Date:
Subject: Re: datestyle question
Next
From: "Josh Tolley"
Date:
Subject: Re: Feature Request - Defining default table space for Indexes in Conf file