Re: [HACKERS] 'Waiting on lock'
От | Gregory Stark |
---|---|
Тема | Re: [HACKERS] 'Waiting on lock' |
Дата | |
Msg-id | 87lkeg8a62.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответы |
Re: [HACKERS] 'Waiting on lock'
Re: [HACKERS] 'Waiting on lock' Re: [HACKERS] 'Waiting on lock' Re: [HACKERS] 'Waiting on lock' |
Список | pgsql-patches |
>> * 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
Вложения
В списке pgsql-patches по дате отправления: