Re: WALInsertLock contention

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WALInsertLock contention
Date: 2011-06-09 02:21:18
Message-ID: BANLkTi=hwxD+yYfxkRGmC9zFAG_V=XszpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 8, 2011 at 6:49 PM, Jim Nasby <jim(at)nasby(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-06-09 02:36:57 Re: gcc 4.6 and hot standby
Previous Message Kevin Grittner 2011-06-09 02:17:04 Re: SSI work for 9.1