Re: WALInsertLock contention - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WALInsertLock contention
Date
Msg-id BANLkTi=hwxD+yYfxkRGmC9zFAG_V=XszpA@mail.gmail.com
Whole thread Raw
In response to Re: WALInsertLock contention  (Jim Nasby <jim@nasby.net>)
Responses Re: WALInsertLock contention
List pgsql-hackers
On Wed, Jun 8, 2011 at 6:49 PM, Jim Nasby <jim@nasby.net> wrote:
>> 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?

Sure, but that happens all the time.  See pg_stat_bgwriter.buffers_backend.

> If the buffer was truly private, would that still be an issue?

I'm not sure if you mean make the buffer private or make the WAL
storage arena private, but I'm pretty well convinced that neither one
can work.

> Perhaps the only way to make that work is multiple WAL streams, as was originally suggested...

Maybe...  but I hope not.  I just found an academic paper on this
subject, about which I will post shortly.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

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