> > ---------- Forwarded message ---------- > From: Simon Riggs <si...@2ndquadrant.com> > To: pgsql-hackers <pgsql-hackers@postgresql.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
lwlock.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
