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
