Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
