Re: Update problem on large table

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
>

In response to

Responses

Browse pgsql-performance by date

  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