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==NULLbut 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
>