Re: WALInsertLock contention

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: WALInsertLock contention
Дата
Msg-id F8B04E38-F6FC-4D81-B48A-BBC09BBFF17A@nasby.net
обсуждение исходный текст
Ответ на Re: WALInsertLock contention  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: WALInsertLock contention  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: SSI work for 9.1
Следующее
От: Alex Hunsaker
Дата:
Сообщение: Re: gcc 4.6 and hot standby