Re: signal handling in plpython - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: signal handling in plpython
Date
Msg-id 299C86D7-2DF9-4A70-A055-E7DCCD2F4668@iki.fi
Whole thread Raw
In response to Re: signal handling in plpython  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: signal handling in plpython  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 14 October 2016 16:22:12 EEST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 10/14/2016 04:05 PM, Tom Lane wrote:
>>> I wrote:
>>>> Py_AddPendingCall is safe to call from a signal handler?  That
>would
>>>> be ... quite remarkable.
>
>> Yes, I believe it is.
>
>>
>https://github.com/python/cpython/blob/4b71e63b0616aa2a44c9b13675e4c8e3c0157481/Python/ceval.c#L422
>
>I don't know whether to laugh or cry, but that code is a joke.  Just
>silently fail if you can't get the lock?

Heh, ok, let me rephrase: I believe it's *intended* to be callable from a signal handler :). Whether it actually works
isanother question. Perhaps there's some mitigating conditions there, I don't know.
 

For our use case, it's actually not too bad if Py_AddPendingCall gives up and does nothing. Then the python function
willsimply not be interrupted until next SPI call, which is the current situation anyway.
 

- Heikki



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.