From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WALInsertLock tuning |
Date: | 2011-06-07 15:36:29 |
Message-ID: | 4DEE457D.5050309@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07.06.2011 10:55, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 8:27 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> You would only need to do it just before you write out the WAL. I guess
>> you'd need to grab WALInsertLock in XLogWrite() to prevent more WAL records
>> from being inserted on the page until you're done zeroing it, though.
>
> How would that help?
It doesn't matter whether the pages are zeroed while they sit in memory.
And if you write a full page of WAL data, any wasted bytes at the end of
the page don't matter, because they're ignored at replay anyway. The
possibility of mistaking random garbage for valid WAL only occurs when
we write a partial WAL page to disk. So, it is enough to zero the
remainder of the partial WAL page (or just the next few words) when we
write it out.
That's a lot cheaper than fully zeroing every page. (except for the fact
that you'd need to hold WALInsertLock while you do it)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-06-07 15:50:23 | Re: BUG #6041: Unlogged table was created bad in slave node |
Previous Message | Kevin Grittner | 2011-06-07 15:29:10 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |