Interrupting long external library calls - Mailing list pgsql-hackers

From Mark Cave-Ayland
Subject Interrupting long external library calls
Date
Msg-id 4FB38090.6010306@ilande.co.uk
Whole thread Raw
Responses Re: Interrupting long external library calls
List pgsql-hackers
Hi all,

One of the issues we've been looking at with PostGIS is how to interrupt 
long-running processing tasks in external libraries, particularly GEOS. 
After a few tests here, it seems that even the existing SIGALRM handler 
doesn't get called if statement_timeout is reached when in an external 
library, e.g. with PostgreSQL 9.0/PostGIS 2.0 trunk/GEOS:

pg90@kentang:~$ ./rel/bin/postgres --single -D data postgis

PostgreSQL stand-alone backend 9.0.7
backend> create database foo;
backend> drop database foo;
backend> show statement_timeout;         1: statement_timeout   (typeid = 25, len = -1, typmod = -1, 
byval = f)        ----         1: statement_timeout = "500ms" (typeid = 25, len = -1, typmod 
= -1, byval = f)        ----
backend> set statement_timeout = '10ms';
backend> create database foo;
ERROR:  canceling statement due to statement timeout
STATEMENT:  create database foo;

(note the following command takes about 3-4s to run but doesn't get 
cancelled)

backend> select st_segmentize('LINESTRING(0 0, 10 0)', 1e-12);
ERROR:  invalid memory alloc request size 1073741824

Is there a way in which we can interrupt long-running external library 
calls that are unable to call the PostgreSQL CHECK_FOR_INTERRUPTS() 
macro directly? If it is possible for standard alarms to work in this 
way then something along the lines of an alarm within PostgreSQL itself 
that manually invokes CHECK_FOR_INTERRUPTS() every 1s while the query is 
running could potentially solve the issue for us.


Many thanks,

Mark.


pgsql-hackers by date:

Previous
From: Brar Piening
Date:
Subject: Re: 9.2 Beta: intersection of daterange
Next
From: Heikki Linnakangas
Date:
Subject: Re: Interrupting long external library calls