Re: 16-bit page checksums for 9.2

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <simon(at)2ndQuadrant(dot)com>,<jim(at)nasby(dot)net>
Cc: <andres(at)anarazel(dot)de>,<aidan(at)highrise(dot)ca>, <stark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 16-bit page checksums for 9.2
Date: 2012-01-04 13:13:35
Message-ID: 4F03FC1F02000025000442F5@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:

> We can either
>
> (1) report all errors on a page, including errors that don't change
> PostgreSQL data. This involves checksumming long strings of zeroes,
> which the checksum algorithm can't tell apart from long strings of
> ones.

What do you mean? Each byte which goes into the checksum, and the
position of that byte influences the outcome once you've got a
non-zero value in sum1. The number of leading NIL bytes would not
affect the outcome unless you seed the calculation with something
non-zero, but including the page header in the calculation seems to
cover that OK.

> (2) report only errors that changed PostgreSQL data.
>
> We already do (1) for WAL CRCs so doing the same thing for page
> checksums makes sense and is much faster.
>
> If enough people think we should do (2) then its a simple change to
> the patch.

To me, (1) makes more sense, but it seems to me you're currently
doing (2) because you check in three parts, skipping the free space
in the middle of the page.

-Kevin

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-01-04 13:28:37 Re: 16-bit page checksums for 9.2
Previous Message Tomas Vondra 2012-01-04 12:24:13 Re: pgstat wait timeout