On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 14 October 2016 16:22:12 EEST, Tom Lane <tgl@sss.pgh.pa.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
worksis 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
willsimply 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.
I'm not sure that kibitzing the way the Python developers chose to
handle this is very helpful. Our job to use the APIs they've exposed,
not second-guess how they implemented them. The comment suggests that
the Python team thought that this would be reliable enough to be
acceptable, and I think we should assume they're right. If they're
wrong, they can fix that in a future release and our use of that API
will work that much better. Sitting on our hands gets us nowhere.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company