Re: WALInsertLock tuning

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

In response to

Responses

Browse pgsql-hackers by date

  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