From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WALInsertLock contention |
Date: | 2011-06-08 22:49:49 |
Message-ID: | F8B04E38-F6FC-4D81-B48A-BBC09BBFF17A@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 still be an issue?
Perhaps the only way to make that work is multiple WAL streams, as was originally suggested...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2011-06-08 22:56:19 | Re: gcc 4.6 and hot standby |
Previous Message | Kevin Grittner | 2011-06-08 22:48:26 | SSI work for 9.1 |