On Mon, Oct 13, 2014 at 10:56 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> I noticed another potential bug: LWLockAcquireCommon doesn't use a volatile
> pointer when it sets the value of the protected variable:
>
>> /* If there's a variable associated with this lock, initialize it
>> */
>> if (valptr)
>> *valptr = val;
>>
>> /* We are done updating shared state of the lock itself. */
>> SpinLockRelease(&lock->mutex);
>
>
> If the compiler or CPU decides to reorder those two, so that the variable is
> set after releasing the spinlock, things will break.
>
>
> The attached patch should fix these two bugs. It is for REL9_4_STABLE; needs
> to be forward-patched ot master too. This fixes the deadlock for me. Anyone
> see any issues with this?
The volatile-ization portion of this should not be forward-ported to
master; in master, spinlock operations have compiler barrier
semantics, and we've accordingly started removing volatile qualifiers
from various parts of the code, including lwlock.c.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
