Re: WALInsertLock contention

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

In response to

Responses

Browse pgsql-hackers by date

  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