Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Tom Lane
Robert Haas writes: > On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane wrote: >> I dunno. If the failure were very low-probability, you could maybe live >> with that behavior, but I'm not sure it is. Presumably the Python >> interpreter loop is taking that lock once per statement (at least), so >> th

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Robert Haas
On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane wrote: > Heikki Linnakangas writes: >> On 14 October 2016 16:22:12 EEST, Tom Lane wrote: >>> 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

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Andres Freund
On 2016-10-14 13:50:35 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > On 14 October 2016 16:22:12 EEST, Tom Lane wrote: > >> 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

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Tom Lane
Heikki Linnakangas writes: > On 14 October 2016 16:22:12 EEST, Tom Lane wrote: >> 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 :). Whe

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Heikki Linnakangas
On 14 October 2016 16:22:12 EEST, Tom Lane wrote: >Heikki Linnakangas 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/pyth

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Mario De Frutos Dieguez
Hi! Following your ideas I've made a test [here ], only in plpython and seems to works pretty well. I've to make more tests and execute the postgres regress too. This ad-hoc solution could be enough for now, we d

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Tom Lane
Heikki Linnakangas 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/

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Heikki Linnakangas
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. That's pretty much the raison d'être for Py_AddPendingCall(). I believe the Python interpreter itself implements signal handler

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Tom Lane
I wrote: > Py_AddPendingCall is safe to call from a signal handler? That would > be ... quite remarkable. I think that a much safer way to proceed would be, rather than asking "how can I mess with the signal handlers", asking "how can I make my python code act like it is sprinkled with CHECK_FOR_

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Tom Lane
Heikki Linnakangas writes: > 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

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Heikki Linnakangas
On 10/14/2016 01:57 PM, Mario De Frutos Dieguez wrote: 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 lo

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Mario De Frutos Dieguez
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 be

Re: [HACKERS] signal handling in plpython

2016-10-14 Thread Heikki Linnakangas
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 CP

[HACKERS] signal handling in plpython

2016-10-13 Thread Mario De Frutos Dieguez
Hello everyone :). First of all, I want to introduce me to this list. My name is Mario de Frutos and I work at CARTO :) 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 proble