Re: Interrupting long external library calls

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.

In response to

Responses

Browse pgsql-hackers by date

  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