Re: lwlocks and starvation

Simon Riggs wrote:
> I'd been thinking about lock release order also, thinking that this
> could be related to the CS storms observed earlier and the apparent
> lock-step behaviour commented upon previously.

As much as I would love to believe this (because it would mean we could 
probably solve the problem pretty easily), I don't think lock release 
order is the (primary) culprit behind the CS storm issue. As I 
understand it, the heavily contended lock in those situations is the 
BufMgrLock, and that is _always_ acquired in exclusive mode.

> ISTM that waking
> shared waiters in xid order would bring the most benefit and minimise
> any data issues. Readers waiting behind an exclusive waiter, where the
> reader has a lower xid might reasonably be woken without a problem since
> they will never see the changes made by the exclusive waiter anyway.

I'm not sure I understand. What "data issues" are you referring to? 
LWLocks are used to protect non-transactional resources (such as shared 
memory data structures), so the relative xids of two waiter processes 
doesn't affect whether they can see each other's modifications (i.e. 
because they always can).

In any case, the idea of considering information such as the xid when 
deciding which waiters to release is interesting. It's not immediately 
apparent to me quite *how* to make use of that info, but it's definitely 
something to consider...

-Neil