On Mon, Dec 6, 2010 at 4:31 PM, felix wrote:
>
> 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 | in transaction | f | 2010-12-01
> 15
Right, pg
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 | in transaction | f | 2010-12-01
15
resulting in: "fastadder_fastadderstatus": scanned 3000 of 58551
On Mon, Dec 06, 2010 at 03:24:31PM -0500, Josh Kupershmidt wrote:
> On Mon, Dec 6, 2010 at 2:48 PM, Jon Nelson wrote:
> > On Mon, Dec 6, 2010 at 1:46 PM, bricklen wrote:
> >> Not sure if anyone replied about killing your query, but you can do it
> >> like so:
> >>
> >> select pg_cancel_backend(5
On Mon, Dec 6, 2010 at 2:48 PM, Jon Nelson wrote:
> On Mon, Dec 6, 2010 at 1:46 PM, bricklen 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
On Mon, Dec 6, 2010 at 1:46 PM, bricklen wrote:
> On Sat, Dec 4, 2010 at 11:45 AM, felix wrote:
>> Ok, I caught one : an update that is stuck in waiting.
>> the first one blocks the second one.
>> ns | 5902 | nssql | UPDATE "fastadder_fastadderstatus" SET "built"
>> = false WHERE "fasta
On Sat, Dec 4, 2010 at 11:45 AM, felix wrote:
> Ok, I caught one : an update that is stuck in waiting.
> the first one blocks the second one.
> ns | 5902 | nssql | UPDATE "fastadder_fastadderstatus" SET "built"
> = false WHERE "fastadder_fastadderstatus"."service_id" = 1
Not sure if any
Ok, I caught one : an update that is stuck in waiting.
the first one blocks the second one.
ns |5902 | nssql | UPDATE "fastadder_fastadderstatus" SET "built"
= false WHERE "fastadder_fastadderstatus"."service_id" = 1
On Fri, Nov 26, 2010 at 6:22 AM, felix wrote:
>
> Hello,
> I have a very large table that I'm not too fond of. I'm revising the design
> now.
> Up until now its been insert only, storing tracking codes from incoming
> webtraffic.
> It has 8m rows
> It appears to insert fine, but simple updates us
Hello,
I have a very large table that I'm not too fond of. I'm revising the design
now.
Up until now its been insert only, storing tracking codes from incoming
webtraffic.
It has 8m rows
It appears to insert fine, but simple updates using psql are hanging.
update ONLY traffic_tracking2010 set s
