Re: Reworking WAL locking - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reworking WAL locking
Date
Msg-id 19399.1203025842@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reworking WAL locking  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Reworking WAL locking  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reworking WAL locking
Next
From: Alvaro Herrera
Date:
Subject: Re: Show INHERIT in \du