>> * Tom Lane ([EMAIL PROTECTED]) 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.
checkpoint-log-messages-fix.patch.gz
Description: Binary data
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
