Re: Killing a data modifying transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: William Temperley <willtemperley(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Killing a data modifying transaction
Date: 2009-06-22 15:22:01
Message-ID: 18381.1245684121@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

William Temperley <willtemperley(at)gmail(dot)com> writes:
> I'm wondering if I happened as I'd started the same query twice.
> The first had work_mem = 1MB so I tried to kill it and started another
> with work_mem = 1000MB, but both were attempting to insert the same id
> into a PK:
> "insert into world (geom, id) select st_union(geom), 1 from adminunit
> where admin_level = '0'".
> Just now when I killed the first process, the other terminated.

Well, that last is expected --- as soon as you kill -9 one backend, the
postmaster is going to force-quit all the others and perform a database
restart. So we don't really know anything more than before.

Given that they'd both be trying to insert the same PK values, it'd be
unsurprising for one of the processes to be blocked waiting to see if
the other one commits. But didn't you say they were both eating CPU?

I'm personally inclined to think some PostGIS oddity here (which means
you might get more help asking about it on the postgis lists). But
that's mere speculation. A stack trace showing where it was looping
would've provided something more to go on ...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2009-06-22 15:30:30 Re: pl/sql resources for pl/pgsql?
Previous Message Todd A. Cook 2009-06-22 15:13:27 Re: FYI: Load times for a largish DB in 8.2 vs. 8.3 vs. 8.4