LWLock Queue Jumping

>
> ---------- Forwarded message ----------
> From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
> To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
> Date: Fri, 28 Aug 2009 20:07:32 +0100
> Subject: LWLock Queue Jumping
>
> WALInsertLock is heavily contended and likely always will be even if we
> apply some of the planned fixes.
>
> Some callers of WALInsertLock are more important than others
>
> * Writing new Clog or Multixact pages (serialized by ClogControlLock)
> * For Hot Standby, writing SnapshotData (serialized by ProcArrayLock)
>
> In these cases it seems like we can skip straight to the front of the
> WALInsertLock queue without problem.
>
> Most other items cannot be safely reordered, possibly no other items.
>
> We already re-order the lock queues when we hold shared locks, so we
> know in principle it is OK to do so. This is an extension of that
> thought.
>
> Implementing this would do much to remove my objection to performance
> issues associated with simplifying the Hot Standby patch, as recently
> suggested by Heikki.
>
> Possible? If so, we can discuss implementation. No worries if not, but
> just a side thought that may be fruitful.

I'd previously implemented this just by copying and pasting and making some
changes, perhaps not the most desirable way but I thought adding another
parameter to all existing invocations would be a bit excessive. The
attached patch will convert the existing LWLockAcquire into
LWLockAcquire_head, rather than adding a new function. Sorry if that is not
the optimal way to send this, I wanted to make it easy to see just the
changes, even though the functions aren't technically the same thing
anymore.

I've tested it fairly thoroughly, in the context of using it in
AdvanceXLInsertBuffer for acquiring the WALWriteLock.

Jeff