>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>
>> Yeah, I wouldn't want one per second. Do we already track how long
>> we've been waiting?
>
> No, because we're *asleep*. You'd have to add an additional
> timeout-interrupt reason. Plus there's a ton of interesting questions
> about what's safe to do from an interrupt service routine.
>
> In fact, I am scandalized to see that someone has inserted a boatload
> of elog calls into CheckDeadLock since 8.2 --- that seems entirely
> unsafe. [ checks revision history... ]
Attached is a patch which moves the messages to ProcSleep(). To do this I had
to move the semaphore signal to unconditionally be signalled whenever
CheckDeadLock() is called regardless of whether it finds a hard deadlock. I'm
not 100% sure that's correct but afaik we only use semaphores to signal state
changes and deal with spurious semaphore firings everywhere.
Incidentally in looking at this I found that the "early deadlock detection"
never seems to fire. Reading the source it seems it ought to be firing
whenever we have a simple two-process deadlock. But instead I only get the
timeout-based detection.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
