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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
