thanks for the replies !,

but actually I did figure out how to kill it

but pb_cancel_backend didn't work.  here's some notes:

this has been hung for 5 days:
ns      |   32681 | nssql   | <IDLE> in transaction | f       | 2010-12-01
15

resulting in:  "fastadder_fastadderstatus": scanned 3000 of 58551 pages,
containing 13587 live rows and 254709 dead rows;
and resulting in general pandemonium


you need to become the postgres superuser to use pg_cancel_backend:
 su postgres
 psql

and then:

select pg_cancel_backend(32681);

but this does not kill the IDLE in transaction processes.
it returns true, but its still there

from the linux shell I tried:

pg_ctl kill INT 32681

but it still will not die

the docs for pg_ctl state:
"Use pb_ctl --help to see a list of supported signal names."

doing so does indeed tell me the names:

HUP INT QUIT ABRT TERM USR1 USR2

but nothing about them whatseover :)

throwing caution to the wind:

pg_ctl kill TERM 32681

and that did it

ran VACUUM and now performance has returned to normal.

lessons learned.

I guess as Josh says, pg_cancel_backend is the same as SIGINT, which also
failed for me using pg_ctl.
not sure why.  the hung transaction was doing something like update table
set field = null where service_id = x



On Mon, Dec 6, 2010 at 9:26 PM, Kenneth Marshall <k...@rice.edu> wrote:

> On Mon, Dec 06, 2010 at 03:24:31PM -0500, Josh Kupershmidt wrote:
> > On Mon, Dec 6, 2010 at 2:48 PM, Jon Nelson 
> > <jnelson+pg...@jamponi.net<jnelson%2bpg...@jamponi.net>>
> wrote:
> > > On Mon, Dec 6, 2010 at 1:46 PM, bricklen <brick...@gmail.com> wrote:
> > >> Not sure if anyone replied about killing your query, but you can do it
> like so:
> > >>
> > >> select pg_cancel_backend(5902); ?-- assuming 5902 is the pid of the
> > >> query you want canceled.
> > >
> > > How does this differ from just killing the pid?
> >
> > pg_cancel_backend(5902) does the same thing as:
> >   kill -SIGINT 5902
> >
> > Josh
> >
>
> Yes, but you can use it from within the database. The kill command
> requires shell access to the backend.
>
> Cheers,
> Ken
>

Reply via email to