From: | Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Interrupting long external library calls |
Date: | 2012-05-16 11:30:25 |
Message-ID: | 4FB38FD1.4030407@ilande.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16/05/12 11:39, Heikki Linnakangas wrote:
>> 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:
>
> If you interrupt an external library call, it might leave memory in an
> inconsistent state, or some other such thing. It's not generally safe to
> interrupt arbitrary 3rd party code.
>
> However, if you're absolutely positively sure that the library function
> can tolerate that, you can set "ImmediateInterruptOK = true" before
> calling it. See e.g PGSemaphoreLock() on how that's done before starting
> to sleep on a semapgore.
Hi Heikki,
Yes that appears to work fine on the surface - just testing now to
determine what state everything is left in when queries are aborted
prematurely.
Many thanks,
Mark.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-05-16 11:46:17 | Re: Interrupting long external library calls |
Previous Message | Heikki Linnakangas | 2012-05-16 10:39:05 | Re: Interrupting long external library calls |