Re: signal handling in plpython

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: signal handling in plpython
Дата
Msg-id 12585.1476467435@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: signal handling in plpython  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: signal handling in plpython  (Andres Freund <andres@anarazel.de>)
Re: signal handling in plpython  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD
Следующее
От: Andres Freund
Дата:
Сообщение: Re: signal handling in plpython