Re: 16-bit page checksums for 9.2 - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id 4F081DE2.4010505@enterprisedb.com
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Re: 16-bit page checksums for 9.2  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
On 07.01.2012 12:14, Simon Riggs wrote:
> page_checksums is an optional parameter, so you can turn it on or off
> on the standby as you wish. People frequently have a standby dedicated
> to HA and other standbys for queries. So this is all normal and
> natural.

There needs to be a well-documented way of turning it on/off. In 
particular, from off to on. If you ever flip it off even for a minute, 
pages with invalid checksums start to appear in the data directory, and 
if you then turn it on again, you start getting errors. Perhaps there 
needs to be a third setting, calculate-but-dont-verify, where CRCs are 
updated but existing CRCs are not expected to be correct. And a utility 
to scan through your database and fix any incorrect CRCs, so that after 
that's run in calculate-but-dont-verify mode, you can safely turn 
checksums on.

Even better would be a way to make that process robust so that you can't 
do a pilot error and turn page_checksums 'on' when it's not safe to do 
so. Otherwise when you get a checksum error, your first thought is going 
to be "hmm, I wonder if anyone ever turned page_checksums 'off' by 
accident anytime in the past, or if this is a genuine error".

> page_checksums will default to 'off' in the final patch anyway, in my
> understanding.

That makes the need for such a facility even more important. Otherwise 
there's no safe way to ever switch it from off to on.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: LWLOCK_STATS
Next
From: Simon Riggs
Date:
Subject: Re: Intermittent regression test failures from index-only plan changes