Greg Stark wrote: > On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs<si...@2ndquadrant.com> wrote: >> WALInsertLock is heavily contended and likely always will be even if we >> apply some of the planned fixes. > > I've lost any earlier messages, could you resend the raw data on which > this is based?
I don't have any pointers right now, but WALInsertLock does often show up as a bottleneck in write-intensive benchmarks. >> 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. > > Reordering some exclusive lockers ahead of other exclusive lockers > won't reduce the amount of time the lock is held at all. Are you > saying the reason to do it is to reduce time spent waiting on this > lock while holding other critical locks? That's what I thought. I don't know about the clog/multixact issue, it doesn't seem like it would be too bad, given how seldom new clog or multixact pages are written. The Hot Standby thing has been discussed, but no-one has actually posted a patch which does the locking correctly, where the ProcArrayLock is held while the SnapshotData WAL record is inserted. So there is no evidence that it's actually a problem, we might be making a mountain out of a molehill. It will have practically no effect on throughput, given how seldom SnapshotData records are written (once per checkpoint), but if it causes a significant bump to response times, that might be a problem. This is a good idea to keep in mind, but right now it feels like a solution in search of a problem. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
