Re: pg_cancel_backend() does not work with buzz queries
От | Sergey Konoplev |
---|---|
Тема | Re: pg_cancel_backend() does not work with buzz queries |
Дата | |
Msg-id | c3a7de1f0710030445u2753f92bt7a8cc27ae3965e5c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_cancel_backend() does not work with buzz queries (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: pg_cancel_backend() does not work with buzz queries
|
Список | 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 по дате отправления: