Re: signal handling in plpython

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: signal handling in plpython
Дата
Msg-id 13489.1476468519@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: signal handling in plpython  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> 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
>> 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.

Well, the comment implies strongly that they expect it to be used in
situations where the signal handler would execute on a different thread
from the python interpreter loop.  So the proposed Postgres usage is
really not within the intended scope of use of the function.

> Sitting on our hands gets us nowhere.

I'm not sure where I said to sit on our hands.  I pointed to the Python
trace callback as a likely implementation that would not suffer from this
problem --- and wouldn't require us to invent safe ways to install
extension callback hooks in our signal handlers, which is not a trivial
problem either.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.
Следующее
От: Gilles Darold
Дата:
Сообщение: Re: Patch to implement pg_current_logfile() function