Re: releaseOk and LWLockWaitForVar - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: releaseOk and LWLockWaitForVar
Date
Msg-id CAA4eK1LM83LsuPpaVoc1-XVT5cE6ZJ4NpRNDWONYF3E+QaFsVg@mail.gmail.com
Whole thread Raw
In response to releaseOk and LWLockWaitForVar  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: releaseOk and LWLockWaitForVar  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Tue, Jun 17, 2014 at 5:47 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>
> Hi Heikki, All,
>
> Amit just pointed me to a case where the lwlock scalability patch
> apparently causes problems and I went on to review it and came across
> the following problem in 9.4/master:
> LWLockWaitForVar() doesn't set releaseOk to true when waiting
> again. Isn't that a bug? What if there's another locker coming in after
> LWLockWaitForVar() returns from the PGSemaphoreLock() but before it has
> acquire the spinlock?

I also think above mentioned scenario is a problem if releaseOk
is not set to true in above case.

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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Atomics hardware support table & supported architectures
Next
From: Robert Haas
Date:
Subject: Re: replication identifier format