Re: Reworking WAL locking

On Thu, 2008-02-14 at 16:50 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Thu, 2008-02-14 at 13:52 -0500, Tom Lane wrote:
> >> [ still staring at the code ... ]  Something that might be interesting
> >> though is to try to move some of the buffer control logic overhead out
> >> of WALInsertLock's domain and into WALWriteLock's domain.
> 
> > I like this one because its another example that contention is not
> > static, seems like its more often cyclical. The WALInsertLock is held
> > longer than normal when we cross page boundaries, creating a pulsing
> > effect thru the lock queue.
> 
> Yeah, significantly longer than normal if you assume the normal case is
> to write a WAL record that's much less than a full page.  But has anyone
> seen direct evidence that that's an important effect?  I was just
> proposing this on speculation --- if there's already evidence that that
> behavior is a problem, it'd be interesting to see it.

A tracepoint in AdvanceXLInsertBuffer() would help there.

I would expect lock time to vary with number of cache lines touched
(approximated by record size) as well as whether the record crossed a
page boundary. Very large WAL records are more likely to cross
boundaries, so the effect will show itself most when we write small WAL
records.

> BTW, we'd probably need to do something like this even if we then go
> forward with your original idea.  If we're going to allow multiple
> backends to be inserting WAL records into the-same-or-different WAL
> buffers concurrently, we can't have that same code responsible for
> initializing empty buffers.

You've sold me already!

I will return to the other part of the idea, but just too busy now to
think and reply in full. I agree with the issues you raised earlier.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com