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

From Sergey Konoplev
Subject Re: pg_cancel_backend() does not work with buzz queries
Date
Msg-id c3a7de1f0710030445u2753f92bt7a8cc27ae3965e5c@mail.gmail.com
Whole thread Raw
In response to Re: pg_cancel_backend() does not work with buzz queries  (Magnus Hagander <magnus@hagander.net>)
Responses Re: pg_cancel_backend() does not work with buzz queries  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
> > 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.

How can we find it out?

> > 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 :(

Yes I know it but I have no choice :(

pgsql-general by date:

Previous
From: "Josh Tolley"
Date:
Subject: Re: Feature Request - Defining default table space for Indexes in Conf file
Next
From: Richard Huxton
Date:
Subject: Re: pg_cancel_backend() does not work with buzz queries