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@xxxxxxxx> wrote:
Yes, but you can use it from within the database. The kill commandOn 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@xxxxxxxxxxx> wrote:
> > On Mon, Dec 6, 2010 at 1:46 PM, bricklen <bricklen@xxxxxxxxx> 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
