Re: releaseOk and LWLockWaitForVar

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: heikki(at)anarazel(dot)de, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: releaseOk and LWLockWaitForVar
Date: 2014-06-23 14:38:42
Message-ID: CAA4eK1LM83LsuPpaVoc1-XVT5cE6ZJ4NpRNDWONYF3E+QaFsVg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 17, 2014 at 5:47 PM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-23 14:45:51 Re: replication identifier format
Previous Message Robert Haas 2014-06-23 14:29:54 Re: Atomics hardware support table & supported architectures