From: | felix <crucialfelix(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Update problem on large table |
Date: | 2010-12-06 21:31:44 |
Message-ID: | AANLkTi=yE1d8ETo-+hVCRGBUbnhz2iMWfSyJXJwXPmyo@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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 <ktm(at)rice(dot)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(at)jamponi(dot)net<jnelson%2Bpgsql(at)jamponi(dot)net>>
> wrote:
> > > On Mon, Dec 6, 2010 at 1:46 PM, bricklen <bricklen(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | John Papandriopoulos | 2010-12-06 21:48:57 | Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT |
Previous Message | Kenneth Marshall | 2010-12-06 20:26:56 | Re: Update problem on large table |