ST_LineToCurve hangs indefintely

[robe]

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)

[robe]

Okay I just tested this on my production PostgreSQL 11

PostgreSQL 11.1, compiled by Visual C++ build 1914, 64-bit
POSTGIS="2.5.1 r17027" [EXTENSION] PGSQL="110" GEOS="3.7.0-CAPI-1.11.0 3.7.1" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.4, released 2018/03/19" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" (core procs from "2.5.0 r16836" need upgrade) RASTER (raster procs from "2.5.0 r16836" need upgrade)

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.

PostgreSQL 11.0 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit POSTGIS="3.0.0dev r16983" PGSQL="94" (procs need upgrade for use with "110") GEOS="3.7.0-CAPI-1.11.0 673b9939" PROJ="Rel. 5.2.0, September 15th, 2018" GDAL="GDAL 2.3.1, released 2018/06/22" LIBXML="2.7.8" LIBPROTOBUF="1.2.1" (core procs from "2.4.6 r17057" need upgrade) RASTER (raster procs from "2.4.6 r17057" need upgrade)

So this does appear to be a recent development. Still haven't nailed it down to PostGIS or PostgreSQL at fault yet.

[robe]

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

[Algunenano]

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

[Algunenano]

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

[dbaston]

Will take a look. Thanks for the report.

[Algunenano]

A simpler test case:

Select St_Area('SRID=4326;CURVEPOLYGON(CIRCULARSTRING(30 40,-50 39.9999999999999,30 40))');

[Algunenano]

This was fixed by r17122