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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers