ST_ConvexHull is uninterruptible

[strk]

Example:

select st_convexhull(st_collect(ST_Segmentize(ST_MakeLine(ST_MakePoint(-100+x, -100-x),ST_MakePoint(100-x,100+x)), 10))) from generate_series(0,10000) x;

[strk]

The query above takes 30 seconds to interrupt, with statement_timeout set to 1000 (1 second).

[strk]

NOTE: by adding another 0 to the generate_series I could crash the backend (OOM killer, I'm afraid)

[strk]

OOM Killer confirmed:

Oct 23 17:15:49 localhost kernel: [12808.652197] Out of memory: Kill process 15751 (postgres) score 684 or sacrifice child

[strk]

A memory-friendlier example (takes around 5.2GB of RAM max):

time psql -f - <<EOF
set statement_timeout to 5000; -- 5 seconds
select st_npoints(st_convexhull(st_collect(ST_Segmentize(ST_Rotate(ST_MakeLine(ST_MakePoint(0+x, 0),ST_MakePoint(400+x,400)), radians(x%180)), 1)))) from generate_series(0,100000) x;
EOF

The above runs in 52 seconds, while the timeout asked for a max of 5 seconds (you may need to allow for a slightly longer run in order to enter the ST_ConvexHull part).

[strk]

This is with GEOS="3.5.0dev-CAPI-1.9.0 r4002"

[robe]

This interrupts now just fine. Just tested.

[strk]

Does it have an automated test yet ? (I know, automated tests for interruption are fragile still..)

[robe]

I don't think so and probably wouldn't be a good idea until we make the interruption tests less fragile. As it is I have it turned off on debbie and winnie. We should probably turn it off on dronie as well since it errors out a lot because of them.

[strk]

I still think it would be good to have the test here, by policy (all fixes need testing).