On Feb12, 2014, at 12:55 , MauMau <maumau307@gmail.com> wrote:
> From: "Andres Freund" <andres@2ndquadrant.com>
>> It's x86, right? Then it's unlikely to be actual unordered memory
>> accesses, but if the compiler reordered:
>> LOG_LWDEBUG("LWLockRelease", T_NAME(l), T_ID(l), "release waiter");
>> proc = head;
>> head = proc->lwWaitLink;
>> proc->lwWaitLink = NULL;
>> proc->lwWaiting = false;
>> PGSemaphoreUnlock(&proc->sem);
>> to
>> LOG_LWDEBUG("LWLockRelease", T_NAME(l), T_ID(l), "release waiter");
>> proc = head;
>> proc->lwWaiting = false;
>> head = proc->lwWaitLink;
>> proc->lwWaitLink = NULL;
>> PGSemaphoreUnlock(&proc->sem);
>> which it is permitted to do, yes, that could cause symptoms like you
>> describe.
>
> Yes, the hang occurred with 64-bit PostgreSQL 9.2.4 running on RHEL6 for x86_64.
> The PostgreSQL was built with GCC.
The relevant part of the disassembled binary you attached seems to be
Dump of assembler code for function LWLockRelease:
...
0x0000000000647f47 <LWLockRelease+519>: lea 0x10(%rcx),%rdi
0x0000000000647f4b <LWLockRelease+523>: movq $0x0,0x48(%rcx)
0x0000000000647f53 <LWLockRelease+531>: movb $0x0,0x41(%rcx)
0x0000000000647f57 <LWLockRelease+535>: callq 0x606210 <PGSemaphoreUnlock>
I haven't checked the offsets, but since lwWaitLink is an 8-byte quantity
and lwWaiting a single-byte quantity, it's pretty much certain that the
first store updates lwWaitLink and the second lwWaiting. Thus, no reordering
seems to have taken place here...
best regards,
Florian Pflug
