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