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

Re: Page Checksums

From: Jim Nasby <jim(at)nasby(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Page Checksums
Date: 2012-01-04 00:22:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Dec 28, 2011, at 3:31 AM, Simon Riggs wrote:
> On Wed, Dec 28, 2011 at 9:00 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>  What I'm not too clear
>> about is whether a 16-bit checksum meets the needs of people who want
>> checksums.
> We need this now, hence the gymnastics to get it into this release.
> 16-bits of checksum is way better than zero bits of checksum, probably
> about a million times better (numbers taken from papers quoted earlier
> on effectiveness of checksums).
> The strategy I am suggesting is 16-bits now, 32/64 later.

What about allowing for an initdb option? That means that if you want binary compatibility so you can pg_upgrade then you're stuck with 16 bit checksums. If you can tolerate replicating all your data then you can get more robust checksumming.

In either case, it seems that we're quickly approaching the point where we need to start putting resources into binary page upgrading...
Jim C. Nasby, Database Architect                   jim(at)nasby(dot)net
512.569.9461 (cell)               

In response to

pgsql-hackers by date

Next:From: Brad DavisDate: 2012-01-04 00:24:06
Subject: Re: [patch] Improve documentation around FreeBSD Kernel Tuning
Previous:From: Tom LaneDate: 2012-01-04 00:11:35
Subject: Re: Should I implement DROP INDEX CONCURRENTLY?

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