Opened 6 years ago
Closed 5 years ago
#4282 closed defect (fixed)
ST_LineToCurve hangs indefintely
Reported by: | robe | Owned by: | dbaston |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 3.0.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description (last modified by )
I thought I had tested this in 2.5 and garden tests ran to completion.
On trunk branch however, for PostgreSQL 12, this test hangs indefinitely. I let it sit there and woke up 5 hrs later and it was still stuck.
SELECT ST_Area(foo1.the_geom) As result FROM ((SELECT ST_LineToCurve(ST_Buffer(ST_SetSRID(ST_Point(i,j),4326), j)) As the_geom FROM generate_series(-10,50,10) As i CROSS JOIN generate_series(40,70, 20) As j ORDER BY i, j, i*j) ) As foo1 LIMIT 10;
I'm guessing it's not the ST_Area and most likely the ST_LineToCurve at fault here. In addition to hanging indefinitely, it's not cancellable
I'll isolate it down to that and if it's a pg12 issue or a PostGIS 3.0 issue.
This I ran against PostgreSQL 12 head as of 12/27/2018
version --------------------------------------------------------------------------------------------------------------------------------- PostgreSQL 12devel on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit (1 row) postgis_full_version ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- POSTGIS="3.0.0dev r17118" [EXTENSION] PGSQL="120" GEOS="3.7.0-CAPI-1.11.0 673b9939" SFCGAL="1.3.2" PROJ="Rel. 5.2.0, September 15th, 2018" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" (1 row)
Change History (8)
comment:1 by , 6 years ago
Description: | modified (diff) |
---|
comment:2 by , 6 years ago
comment:3 by , 6 years ago
Owner: | changed from | to
---|
Blaming Dan for this per Raul's suggestion:
<Algunenano> It's stuck around lwarc_linearize, let's blame Dan [10:44] <robe2> and I couldn't cancel it either [10:44] <Algunenano> Yeah, it doesn't allocate memory so it's not cancelable unless we call the signal handler manually at at some point
comment:4 by , 6 years ago
In my system it seems to get stuck in lwarc_linearize:
(gdb) bt #0 0x00007f591b06cc6e in lwarc_linearize (to=<optimized out>, p1=<optimized out>, p2=0xc049000000000000, p3=0x403e000000000000, tol=32, tolerance_type=LW_LINEARIZE_TOLERANCE_TYPE_SEGS_PER_QUAD, flags=<optimized out>) at lwstroke.c:445 #1 lwcircstring_linearize (icurve=<optimized out>, tol=32, tolerance_type=<optimized out>, flags=<optimized out>) at lwstroke.c:497 #2 0x00007f591b06c46b in lwcurvepoly_linearize (curvepoly=0x561a9557fcf0, tol=32, tolerance_type=LW_LINEARIZE_TOLERANCE_TYPE_SEGS_PER_QUAD, flags=0) at lwstroke.c:619 #3 0x00007f591b0594bb in lwcurvepoly_area (curvepoly=0x561a9557fcf0) at lwcurvepoly.c:139 #4 0x00007f591afde4ef in ST_Area (fcinfo=0x561a9559e888) at lwgeom_functions_basic.c:277 #5 0x0000561a93192250 in ExecInterpExpr (state=<optimized out>, econtext=<optimized out>, isnull=0x7ffdcc335aaf) at execExprInterp.c:678 #6 0x0000561a931a2625 in ExecEvalExprSwitchContext (state=0x561a9559e700, econtext=0x561a95570100, isNull=0xa0d8412365b60051) at ../../../src/include/executor/executor.h:303 #7 ExecProject (projInfo=<optimized out>) at ../../../src/include/executor/executor.h:337 #8 ExecScan (node=<optimized out>, accessMtd=0x561a931c97e0 <SubqueryNext>, recheckMtd=0x561a9559e700) at execScan.c:201 #9 0x0000561a931bbb14 in ExecProcNode (node=<optimized out>) at ../../../src/include/executor/executor.h:237
comment:5 by , 6 years ago
Checking that loop I see that the increment is 0, so it just loops indefinitely:
(gdb) p increment $1 = 0
Last ticket working around that code was #3719
comment:7 by , 6 years ago
A simpler test case:
Select St_Area('SRID=4326;CURVEPOLYGON(CIRCULARSTRING(30 40,-50 39.9999999999999,30 40))');
Okay I just tested this on my production PostgreSQL 11
and it returned answers within 100ms.
I tested it on my PostgreSQL 11 mingw setup against an earlier PostGIS 3.0 and it again returned answers in < 100ms.
So this does appear to be a recent development. Still haven't nailed it down to PostGIS or PostgreSQL at fault yet.