Greg Stark wrote:
> On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs<simon@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
