Re: [HACKERS] 'Waiting on lock'

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] 'Waiting on lock'
Date: 2007-06-19 11:18:29
Message-ID: 87lkeg8a62.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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.

Attachment Content-Type Size
checkpoint-log-messages-fix.patch.gz application/octet-stream 1.6 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Heikki Linnakangas 2007-06-19 12:04:24 Re: Load Distributed Checkpoints, revised patch
Previous Message Gregory Stark 2007-06-19 10:39:57 Re: WIP: rewrite numeric division