Re: 16-bit page checksums for 9.2

On Thu, Dec 29, 2011 at 11:08:43AM -0600, Kevin Grittner wrote:
> > Heikki Linnakangas  wrote:
> > Simon Riggs wrote:
>  
> >> OK, then we are talking at cross purposes. Double write buffers,
> >> in the way you explain them allow us to remove full page writes.
> >> They clearly don't do anything to check page validity on read.
> >> Torn pages are not the only fault we wish to correct against...
> >> and the double writes idea is orthogonal to the idea of checksums.
> > 
> > The reason we're talking about double write buffers in this thread
> > is that double write buffers can be used to solve the problem with
> > hint bits and checksums.

> Of course, it will be a big plus if we can roll this out in 9.2 in
> conjunction with a double-write feature.  Not only will double-write
> probably be a bit faster than full_page_writes in the WAL log, but it
> will allow protection against torn pages on hint-bit-only writes
> without adding those writes to the WAL or doing any major
> rearrangement of where they sit that would break pg_upgrade.

[Thanks for your recent thread summaries.]

A double-write buffer, like a WAL-logged full-page image, is a technique for
performing atomic writes wider than those automatically provided by components
further down the storage stack.  The two strategies have different performance
characteristics, and we're told that a double-write buffer would better serve us
overall.  However, its benefits would not be *greater* for hint-only writes than
for any other write.  For that reason, I think we should consider these changes
independently.  With page checksums enabled, remove the hazard of torn hint-only
writes by ensuring that a WAL FPI has flushed since the last checkpoint.  When
necessary, emit an FPI-only record.  Separately, optimize first-since-checkpoint
writes by replacing FPIs with double-write buffers.  The double-write patch will
reduce the added WAL of the checksum/safe-hint-updates patch to zero.  If the
double-writes patch founders, we'll just have more-costly, yet equally reliable,
page checksums.

nm