Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease

On 02/14/2014 08:28 PM, Andres Freund wrote:
> On 2014-02-14 20:23:32 +0400, knizhnik wrote:
>>>> we'll trade correctness for cleanliness if we continue to reset lwWaitLink
>>>> without protecting against the race. That's a bit of a weird trade-off to make.
>>>
>>> It's not just cleanliness, it's being able to actually debug crashes.
>>
>>
>> Frankly speaking I do not understand why elimination of resetting of lwWaitLink was considered to be bad idea.
>> Resetting this pointer to NULL will not help much to analyze crash dumps, because right now it is possible that lwWaitLink==NULL but process in waiting for a lock and linked in the list
>> (if it is the last element of the list). So the fact that lwWaitLink==NULL actually gives not so much useful information.
>
> At the moment if you connect to a live pg or a crash dump, investigating
> the wait links allows you to somewhat sensibly determine which backends
> are waiting for a lock and whether they are part of a queue. If they
> aren't reset anymore that will tell you nothing, so you'll need to
> connect to all pg instances to debug issues.

Why it is not enough to inspect lwWaiting flag?
In any case, resetting lwWaitLink can be safely done in awakened process:

if (!proc->lwWaiting) {
>>> proc->lwWaitLink = NULL;
break;
}

>
> Greetings,
>
> Andres Freund
>