Robert Haas <> writes:
> On Fri, Oct 14, 2016 at 10:50 AM, Tom Lane <> 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 (
To make changes to your subscription:

Reply via email to