Re: WALInsertLock contention - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: WALInsertLock contention
Date
Msg-id F8B04E38-F6FC-4D81-B48A-BBC09BBFF17A@nasby.net
Whole thread Raw
In response to Re: WALInsertLock contention  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WALInsertLock contention
List pgsql-hackers
On Jun 8, 2011, at 10:15 AM, Robert Haas wrote:
>> 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.

Isn't the only time that you'd need to evict if you ran out of buffers? If the buffer was truly private, would that
stillbe an issue? 

Perhaps the only way to make that work is multiple WAL streams, as was originally suggested...
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: SSI work for 9.1
Next
From: Alex Hunsaker
Date:
Subject: Re: gcc 4.6 and hot standby