From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | MauMau <maumau307(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [9.4 bug] The database server hangs with write-heavy workload on Windows |
Date: | 2014-10-13 15:02:33 |
Message-ID: | CA+TgmoZpwk=JpPbLtyu_XYASXpEm7CHt5RuR3MyGxNoarppfRQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 13, 2014 at 10:56 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-10-13 15:03:00 | Re: JsonbValue to Jsonb conversion |
Previous Message | Tom Lane | 2014-10-13 15:01:27 | Re: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD... |