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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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