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
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 |