Re: Killing a data modifying transaction - Mailing list pgsql-general

From Tom Lane
Subject Re: Killing a data modifying transaction
Date
Msg-id 18381.1245684121@sss.pgh.pa.us
Whole thread Raw
In response to Re: Killing a data modifying transaction  (William Temperley <willtemperley@gmail.com>)
Responses Re: Killing a data modifying transaction
List pgsql-general
William Temperley <willtemperley@gmail.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

pgsql-general by date:

Previous
From: "Todd A. Cook"
Date:
Subject: Re: FYI: Load times for a largish DB in 8.2 vs. 8.3 vs. 8.4
Next
From: Johan Nel
Date:
Subject: Re: Build in spatial support vs. PostGIS