Horton

Re: WALInsertLock tuning

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-07T15:36:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Introduce compact WAL record for the common case of commit (non-DDL).

On 07.06.2011 10:55, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 8:27 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.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