Re: LWLock deadlock and gdb advice

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LWLock deadlock and gdb advice
Date: 2015-07-30 18:14:22
Message-ID: 20150730181422.GA11473@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-07-30 17:36:52 +0300, Heikki Linnakangas wrote:
> In 9.4, LWLockAcquire holds the spinlock when it marks the lock as held,
> until it has updated the variable. And LWLockWaitForVar() holds the spinlock
> when it checks that the lock is held and that the variable's value matches.
> So it cannot happen on 9.4.

The first paragraph talked about "the same value", but that was just
referring to it not yet having been cleared i think...

> To reiterate, with 9.5, it's possible that a backend is sleeping in
> LWLockWaitForVar(oldvar=123), even though the lock is currently held by
> another backend with value 124. That seems wrong, or surprising at the very
> least.

With my patch that can't really happen that way though? The value is
re-checked after queuing. If it has changed by then we're done. And if
it hasn't yet changed we're guaranteed to be woken up once it's being
changed?

I generaly don't mind adding some sort of flag clearing or such, but I'd
rather not have it in the retry loop in the general LWLockAttemptLock
path - I found that very small amounts of instructions in there have a
measurable impact.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-07-30 18:22:33 Re: Volatility of pg_xact_commit_timestamp() and pg_last_committed_xact()
Previous Message Alvaro Herrera 2015-07-30 18:14:13 Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c