Re: WALInsertLock contention

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: WALInsertLock contention
Дата
Msg-id BANLkTikm-ryoUq_y3E8h_pwVC+nq3t9bew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WALInsertLock contention  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: WALInsertLock contention  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
On Wed, Jun 8, 2011 at 10:18 AM, Merlin Moncure <mmoncure@gmail.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Error in PQsetvalue
Следующее
От: Tom Lane
Дата:
Сообщение: Re: reindex creates predicate lock on index root