On Mon, Oct 13, 2014 at 10:56 AM, Heikki Linnakangas
<hlinnakan...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to