Re: releaseOk and LWLockWaitForVar - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: releaseOk and LWLockWaitForVar
Date
Msg-id CAA4eK1LeUWz_2oa+fzmvT-8kAaE4HddAfaCGd5_R78kXSDOgDQ@mail.gmail.com
Whole thread Raw
In response to Re: releaseOk and LWLockWaitForVar  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Mon, Jun 23, 2014 at 10:10 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> On 06/23/2014 05:38 PM, Amit Kapila wrote:
>>
>> While looking at function LWLockWaitForVar(), espacially below
>> code:
>>
>> TRACE_POSTGRESQL_LWLOCK_ACQUIRE(T_NAME(l), T_ID(l), LW_EXCLUSIVE);
>>
>> I think in this function tracing is done considering the Exclusive lock
>> is acquired, however it might have granted access because of
>> variable updation.  Basically this function's trace doesn't distinguish
>> whether the access is granted due to the reason that there is no other
>> exclusive locker or variable is updated.
>
>
> Yeah. Not sure it's worth it to add new TRACE points for this, I'm not really familiar with the way the traces work or how people use them.

Even if we don't want to add new trace points for new usage, I
think using existing might give wrong information to people who
want to use Dynamic tracing.


Another thing I have noticed is that docs are not updated for trace
macro's
TRACE_POSTGRESQL_LWLOCK_ACQUIRE_OR_WAIT
TRACE_POSTGRESQL_LWLOCK_ACQUIRE_OR_WAIT_FAIL

Information related to existing tracing macro's is present at below link:

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER TABLESPACE MOVE command tag tweak
Next
From: Noah Misch
Date:
Subject: Re: Use a signal to trigger a memory context dump?