Re: WALInsertLock contention

On Wed, Jun 8, 2011 at 10:18 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> One point i'm missing though.  Getting back to your original idea, how
> does writing to shmem prevent you from having to keep buffers pinned?
> I'm reading your comment here:
> "Those buffers are stamped with a fake LSN that
> points back to the per-backend WAL buffer, and they can't be written
> until the WAL has been moved from the per-backend WAL buffers to the
> main WAL buffers."
>
> That suggests to me that you have to keep them pinned anyways.  I'm
> still a bit fuzzy on how the per-backend buffers being in shm conveys
> any advantage.  IOW, (trying not to be obtuse) under what
> circumstances would backend A want to read from or (especially) write
> to backend B's wal buffer?

If backend A needs to evict a buffer with a fake LSN, it can go find
the WAL that needs to be serialized, do that, flush WAL, and then
evict the buffer.

IOW, backend A's private WAL buffer will not be completely private.
Only A will write to the buffer, but we don't know who will remove WAL
from the buffer and insert it into the main stream.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company