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: http://www.postgresql.org/mailpref/pgsql-hackers
