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