Re: [9.4 bug] The database server hangs with write-heavy workload on Windows - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [9.4 bug] The database server hangs with write-heavy workload on Windows
Date
Msg-id CA+TgmoZpwk=JpPbLtyu_XYASXpEm7CHt5RuR3MyGxNoarppfRQ@mail.gmail.com
Whole thread Raw
In response to Re: [9.4 bug] The database server hangs with write-heavy workload on Windows  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
Next
From: Andrew Dunstan
Date:
Subject: Re: JsonbValue to Jsonb conversion