Re: Killing a data modifying transaction

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

2009/6/22 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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 ...
>

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2009-06-22 16:52:48 Re: FYI: Load times for a largish DB in 8.2 vs. 8.3 vs. 8.4
Previous Message Scott Marlowe 2009-06-22 15:54:19 Re: Select ranges based on sequential breaks