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
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 |