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

Re: Page Checksums

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Jesper Krogh <jesper(at)krogh(dot)cc>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, David Fetter <david(at)fetter(dot)org>, PGHackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Page Checksums
Date: 2011-12-27 18:46:24
Message-ID: 1325011584.14697.37.camel@jdavis (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, 2011-12-19 at 01:55 +0000, Greg Stark wrote:
> On Sun, Dec 18, 2011 at 7:51 PM, Jesper Krogh <jesper(at)krogh(dot)cc> wrote:
> > I dont know if it would be seen as a "half baked feature".. or similar,
> > and I dont know if the hint bit problem is solvable at all, but I could
> > easily imagine checksumming just "skipping" the hit bit entirely.
> That was one approach discussed. The problem is that the hint bits are
> currently in each heap tuple header which means the checksum code
> would have to know a fair bit about the structure of the page format.

Which is actually a bigger problem, because it might not be the backend
that's reading the page. It might be your backup script taking a new
base backup.

The kind of person to care about CRCs would also want the base backup
tool to verify them during the copy so that you don't overwrite your
previous (good) backup with a bad one. The more complicated we make the
verification process, the less workable that becomes.

I vote for a simple way to calculate the checksum -- fixed offsets of
each page (of course, it would need to know the page size), and a
standard checksum algorithm.

	Jeff Davis

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2011-12-27 18:54:40
Subject: Re: Page Checksums
Previous:From: Jeff DavisDate: 2011-12-27 18:39:36
Subject: Re: Page Checksums

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