Re: LWLock deadlock and gdb advice
От | Andres Freund |
---|---|
Тема | Re: LWLock deadlock and gdb advice |
Дата | |
Msg-id | 20150730181422.GA11473@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: LWLock deadlock and gdb advice (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: LWLock deadlock and gdb advice
|
Список | pgsql-hackers |
On 2015-07-30 17:36:52 +0300, Heikki Linnakangas wrote: > In 9.4, LWLockAcquire holds the spinlock when it marks the lock as held, > until it has updated the variable. And LWLockWaitForVar() holds the spinlock > when it checks that the lock is held and that the variable's value matches. > So it cannot happen on 9.4. The first paragraph talked about "the same value", but that was just referring to it not yet having been cleared i think... > To reiterate, with 9.5, it's possible that a backend is sleeping in > LWLockWaitForVar(oldvar=123), even though the lock is currently held by > another backend with value 124. That seems wrong, or surprising at the very > least. With my patch that can't really happen that way though? The value is re-checked after queuing. If it has changed by then we're done. And if it hasn't yet changed we're guaranteed to be woken up once it's being changed? I generaly don't mind adding some sort of flag clearing or such, but I'd rather not have it in the retry loop in the general LWLockAttemptLock path - I found that very small amounts of instructions in there have a measurable impact. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: