From: | Sandro Santilli <strk(at)keybit(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Interrupting long external library calls |
Date: | 2012-05-16 12:42:45 |
Message-ID: | 20120516124245.GA29548@gnash |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 16, 2012 at 02:46:17PM +0300, Heikki Linnakangas wrote:
> 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.
I'm right now getting the external library into using memory allocator
wrappers so to provide an syntetized OOM condition in an aim to have a
more predictable answer to that.
But CHECK_FOR_INTERRUPTS doesn't return, right ?
Is there another macro for just checking w/out yet acting upon it ?
--strk;
,------o-.
| __/ | Delivering high quality PostGIS 2.0 !
| / 2.0 | http://strk.keybit.net - http://vizzuality.com
`-o------'
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2012-05-16 13:01:00 | Re: Avoiding execution of some functions by query rewriting |
Previous Message | Tom Lane | 2012-05-16 12:35:51 | Re: Avoiding execution of some functions by query rewriting |