Re: 16-bit page checksums for 9.2

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, david(at)fetter(dot)org, 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-07 10:26:42
Message-ID: 4F081DE2.4010505@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-01-07 10:29:43 Re: Intermittent regression test failures from index-only plan changes
Previous Message Simon Riggs 2012-01-07 10:24:38 Re: LWLOCK_STATS