Re: Interrupting long external library calls
От | Mark Cave-Ayland |
---|---|
Тема | Re: Interrupting long external library calls |
Дата | |
Msg-id | 4FB38FD1.4030407@ilande.co.uk обсуждение исходный текст |
Ответ на | Re: Interrupting long external library calls (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Interrupting long external library calls
|
Список | 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.
В списке pgsql-hackers по дате отправления: