Skip site navigation (1) Skip section navigation (2)

Re: Page Checksums + Double Writes

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, simon(at)2ndquadrant(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)commandprompt(dot)com, david(at)fetter(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Page Checksums + Double Writes
Date: 2011-12-27 22:43:23
Message-ID: CAHyXU0xmcwBNGHdDW1NOnE7nUEAEfgKCcnmvDgsmr8N34Btdig@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Dec 27, 2011 at 1:24 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 3. Attack hint bits problem.

A large number of problems would go away if the current hint bit
system could be replaced with something that did not require writing
to the tuple itself.  FWIW, moving the bits around seems like a
non-starter -- you're trading a problem with a much bigger problem
(locking, wal logging, etc).  But perhaps a clog caching strategy
would be a win.  You get a full nibble back in the tuple header,
significant i/o reduction for some workloads, crc becomes relatively
trivial, etc etc.

My first attempt at a process local cache for hint bits wasn't perfect
but proved (at least to me) that you can sneak a tight cache in there
without significantly impacting the general case.  Maybe the angle of
attack was wrong anyways -- I bet if you kept a judicious number of
clog pages in each local process with some smart invalidation you
could cover enough cases that scribbling the bits down would become
unnecessary.  Proving that is a tall order of course, but IMO merits
another attempt.

merlin

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-12-27 23:39:48
Subject: Re: 16-bit page checksums for 9.2
Previous:From: Peter EisentrautDate: 2011-12-27 20:16:13
Subject: Re: Misleading CREATE TABLE error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group