| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Interrupting long external library calls |
| Date: | 2012-05-16 11:46:17 |
| Message-ID: | 4FB39389.7020803@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16.05.2012 14:30, Mark Cave-Ayland wrote:
> On 16/05/12 11:39, Heikki Linnakangas wrote:
>
>> 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.
You're unlikely to catch all problems just by testing. I wouldn't trust
that it's safe unless the library authors specifically mentions that it
is safe to longjump out of the function at any time. Note for example
that if the library function calls back to palloc/pfree, then it's not
safe, because interrupting those functions is not safe.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Girault | 2012-05-16 12:30:00 | Avoiding execution of some functions by query rewriting |
| Previous Message | Mark Cave-Ayland | 2012-05-16 11:30:25 | Re: Interrupting long external library calls |