Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-23 Thread Sergey Konoplev
2007/10/23, Martijn van Oosterhout <[EMAIL PROTECTED]>: > On Tue, Oct 23, 2007 at 09:56:26AM +0400, Sergey Konoplev wrote: > > I took a look at TCP state with netstat: > > > > pgdb:/base/PG-Data # netstat -pna |grep 8590 > > tcp1 0 127.0.0.1:5432 127.0.0.1:35442 > > CLOSE_WAIT

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-23 Thread Martijn van Oosterhout
On Tue, Oct 23, 2007 at 09:56:26AM +0400, Sergey Konoplev wrote: > I took a look at TCP state with netstat: > > pgdb:/base/PG-Data # netstat -pna |grep 8590 > tcp1 0 127.0.0.1:5432 127.0.0.1:35442 > CLOSE_WAIT 8590/postgres: kono CLOSE_WAIT means that the client (in this ca

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-22 Thread Sergey Konoplev
2007/10/17, Sergey Konoplev <[EMAIL PROTECTED]>: > Hello again, > > Sorry for the deal with my answer it was realy hectic week so I > couldn't even check my mail. > > 2007/10/3, Richard Huxton <[EMAIL PROTECTED]>: > > Sergey Konoplev wrote: > > >> Don't forget to cc: the list. > > >> Try not to top

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-17 Thread Sergey Konoplev
2007/10/3, Erik Jones <[EMAIL PROTECTED]>: > On Oct 3, 2007, at 6:47 AM, Richard Huxton wrote: > > > Sergey Konoplev 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. > >> Thanx for your advi

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-17 Thread Sergey Konoplev
2007/10/3, Alvaro Herrera <[EMAIL PROTECTED]>: > Sergey Konoplev escribió: > > > > AFAIK, pl/pgsql does listen for SIGINT during execution, but I don't nkow > > > abuot plpython. > > > > How can we find it out? > > Let's see one of the functions to find out if anyone else can reproduce > the proble

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-17 Thread Sergey Konoplev
Hello again, Sorry for the deal with my answer it was realy hectic week so I couldn't even check my mail. 2007/10/3, Richard Huxton <[EMAIL PROTECTED]>: > Sergey Konoplev wrote: > >> Don't forget to cc: the list. > >> Try not to top-post replies, it's easier to read if you reply below the > >> te

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Erik Jones
On Oct 3, 2007, at 6:47 AM, Richard Huxton wrote: Sergey Konoplev 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. Thanx for your advice. I'm just absolutely worned out. Sorry. Know that feeling - let's s

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes: > 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. It does not,

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Alvaro Herrera
Sergey Konoplev escribió: > > AFAIK, pl/pgsql does listen for SIGINT during execution, but I don't nkow > > abuot plpython. > > How can we find it out? Let's see one of the functions to find out if anyone else can reproduce the problem. -- Alvaro Herrerahttp://w

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Richard Huxton
Sergey Konoplev 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. Thanx for your advice. I'm just absolutely worned out. Sorry. Know that feeling - let's see if we can't sort this out. 1. Is it always the sa

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Sergey Konoplev
> > 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, o

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Magnus Hagander
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

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Richard Huxton
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

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Richard Huxton
Sergey Konoplev wrote: I'm sorry I mean not HUP but KILL Hmm... datname | usename | procpid | current_query | waiting | query_start ---+--+-+-+-+--- transport | belostotskaya_la | 20530

Re: [GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Sergey Konoplev
I'm sorry I mean not HUP but KILL 2007/10/3, Sergey Konoplev <[EMAIL PROTECTED]>: > Hi all, > > I often face with buzz queries (see below). I've looked through pg > manual and huge amount of forums and mail archives and found nothing. > The only solution is to restart postgres server. Moreover I

[GENERAL] pg_cancel_backend() does not work with buzz queries

2007-10-03 Thread Sergey Konoplev
Hi all, I often face with buzz queries (see below). I've looked through pg manual and huge amount of forums and mail archives and found nothing. The only solution is to restart postgres server. Moreover I have to terminate the process using HUP signal to stop the server. transport=# select versi