Re: signal handling in plpython

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mario De Frutos Dieguez <mariodefrutos(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: signal handling in plpython
Date: 2016-10-14 17:53:24
Message-ID: 20161014175324.32ikxm7g5mryfrtv@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-10-14 13:50:35 -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > On 14 October 2016 16:22:12 EEST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 :). Whether it actually works is another 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 will simply not be interrupted until next SPI call, which is the current situation anyway.
>
> 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
> that it can tell if there's something to do. That'd suggest that the
> fraction of time in which the lock is held is not negligible.

Since that's how python's signal handling works, I'm not sure that's
really our problem.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-10-14 17:56:33 Re: signal handling in plpython
Previous Message Tom Lane 2016-10-14 17:50:35 Re: signal handling in plpython