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