From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mario De Frutos Dieguez <mariodefrutos(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: signal handling in plpython |
Date: | 2016-10-14 18:08:39 |
Message-ID: | 13489.1476468519@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gilles Darold | 2016-10-14 18:25:50 | Re: Patch to implement pg_current_logfile() function |
Previous Message | Robert Haas | 2016-10-14 18:07:02 | Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits. |