Re: [HACKERS] signal handling in plpython

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [HACKERS] Signal handling patch (v2) for Synch Rep

On Sat, Nov 15, 2008 at 6:12 AM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > Fujii Masao wrote: >> >> Attached is a patch of signal handling changes for Synch Rep. > > It seems that we wouldn't need to use the BackendPidGetProc function, nor > the new AuxiliaryPidGetProc function, if we stored

Re: [HACKERS] Signal handling patch (v2) for Synch Rep

Fujii Masao wrote: Attached is a patch of signal handling changes for Synch Rep. It seems that we wouldn't need to use the BackendPidGetProc function, nor the new AuxiliaryPidGetProc function, if we stored a PGPROC * instead of the pid in ProcState.procPid. -- Heikki Linnakangas Enterpr

Re: [HACKERS] Signal handling patch (v2) for Synch Rep

On Tue, 2008-11-04 at 21:04 +0900, Fujii Masao wrote: > To be reviewed easily, I'm splitting Synch Rep patch into some pieces. Great idea. I'll be doing that also. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list

[HACKERS] Signal handling patch (v2) for Synch Rep

Hi, To be reviewed easily, I'm splitting Synch Rep patch into some pieces. Attached is a patch of signal handling changes for Synch Rep. http://archives.postgresql.org/pgsql-hackers/2008-09/msg00950.php Though I've posted the WIP patch previously, this is a finished one. Please feel free to comm

[HACKERS] signal handling

hi all: is there any unused signal on postgres? TIA and regards