Re: signal handling in plpython

Hi!

Thank you very much for your quick response :)

We're looking for a solution at plpython level. My two proposals are a
quick "workaround" that let us interrupt using custom signal handlers in
the python code at plpython level. But I'm looking for something more solid
and your proposal, I've been doing this for 3 days hehe, looks great and I
would LOVE to hear more about it and if you can't guide me a bit more in
order to fully understand it :)

We've been thinking to make something like the PostGIS handler
<https://github.com/postgis/postgis/blob/98b2cdb872b5b5bd65606f5bce334d2477b2afc5/postgis/postgis_module.c#L128>
and
have multiple signal handlers: one for the Postgres using
StatementCancelHandler and one for the python code. How does it sound?

Thank you again for your time :)

2016-10-14 12:01 GMT+02:00 Heikki Linnakangas <hlinnaka(at)iki(dot)fi>:

> On 10/13/2016 08:57 PM, Mario De Frutos Dieguez wrote:
>
>> I come here asking for some advice/help because we're facing some
>> unexpected behavior when we want to interrupt functions doing CPU
>> intensive
>> operations in plpython.
>>
>> Our problem is that we're not able to interrupt them when they're making
>> CPU intensive operations. For example, when calculating Moran using PySAL,
>> the SIGINT handler of Postgres is not able to cancel it.
>>
>
> Python code isn't interruptible, but any queries you run within a python
> function are. So if you have a loop in your function that you know will run
> for a long time, you could issue a dummy "SELECT 1" query every once in a
> while. However, that doesn't help, if the long loop is in a library
> function that you have no control over, rather than the PL/python function
> itself.
>
> It would be nice to have a solution for this in plpython itself, so that
> the query cancel was turned into a Python exception. Patches for that would
> be welcome. I think you could use Py_AddPendingCall() from PostgreSQL's
> signal handler, to schedule a call to a function that in turn throws a
> Python exception. That'll need some changes to PostgreSQL's normal signal
> handlers, like die() and StatementCancelHandler() in postgres.c, but it
> seems doable.
>
> - Heikki
>
>