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------' -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers