>> * 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.

Attachment: 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

Reply via email to