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

From William Temperley
Subject Re: Killing a data modifying transaction
Date
Msg-id 439dc11e0906220952k46bdd17dw67915492c6f88a5f@mail.gmail.com
Whole thread Raw
In response to Re: Killing a data modifying transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
2009/6/22 Tom Lane <tgl@sss.pgh.pa.us>:
> 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 ...
>

Yes they were both eating CPU. I've tried the query again and it seems
to be stuck again - the trace has been the same for an hour or so now.
I guess I'd best post to the PostGIS list.

#0  0x00007fae68ec6a75 in
geos::DefaultCoordinateSequence::~DefaultCoordinateSequence () from
/usr/lib/libgeos.so.2
#1  0x00007fae68ed433e in geos::LineString::~LineString () from
/usr/lib/libgeos.so.2
#2  0x00007fae68ed23c7 in geos::LinearRing::~LinearRing () from
/usr/lib/libgeos.so.2
#3  0x00007fae68f20e68 in geos::PolygonBuilder::findEdgeRingContaining
() from /usr/lib/libgeos.so.2
#4  0x00007fae68f21740 in geos::PolygonBuilder::placeFreeHoles () from
/usr/lib/libgeos.so.2
#5  0x00007fae68f218d6 in geos::PolygonBuilder::add () from
/usr/lib/libgeos.so.2
#6  0x00007fae68f21a73 in geos::PolygonBuilder::add () from
/usr/lib/libgeos.so.2
#7  0x00007fae68f20204 in geos::OverlayOp::computeOverlay () from
/usr/lib/libgeos.so.2
#8  0x00007fae68f203e9 in geos::OverlayOp::getResultGeometry () from
/usr/lib/libgeos.so.2
#9  0x00007fae68f206bb in geos::OverlayOp::overlayOp () from
/usr/lib/libgeos.so.2
#10 0x00007fae68ecbfcc in geos::Geometry::Union () from /usr/lib/libgeos.so.2
#11 0x00007fae693c323c in GEOSUnion () from /usr/lib/libgeos_c.so.1
#12 0x00007fae695f3b4a in unite_garray () from
/usr/lib/postgresql/8.3/lib/liblwgeom.so
#13 0x00000000005387bb in ?? ()
#14 0x0000000000538aa7 in ExecAgg ()
#15 0x000000000052e08d in ExecProcNode ()
#16 0x0000000000542b60 in ?? ()
#17 0x0000000000534916 in ExecScan ()
#18 0x000000000052e11d in ExecProcNode ()
#19 0x000000000052d1e2 in ExecutorRun ()
#20 0x00000000005c73c2 in ?? ()
#21 0x00000000005c75d5 in ?? ()
#22 0x00000000005c7e74 in PortalRun ()
#23 0x00000000005c394a in ?? ()
#24 0x00000000005c47bc in PostgresMain ()
#25 0x0000000000599424 in ?? ()
#26 0x000000000059a1a1 in PostmasterMain ()
#27 0x000000000055123e in main ()

Best regards,

Will

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Select ranges based on sequential breaks
Next
From: Tom Lane
Date:
Subject: Re: FYI: Load times for a largish DB in 8.2 vs. 8.3 vs. 8.4