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
<ktm@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+pgsql@jamponi.net> wrote:
> > On Mon, Dec 6, 2010 at 1:46 PM, bricklen <
bricklen@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
>
requires shell access to the backend.
Cheers,
Ken