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

Re: 16-bit page checksums for 9.2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(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-02-29 19:28:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 29, 2012 at 2:09 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 29.02.2012 19:54, Simon Riggs wrote:
>> I'm beginning to lose faith that objections are being raised at a
>> rational level. It's not a panel game with points for clever answers,
>> its an engineering debate about how to add features real users want.
>> And they do want, so let me solve the problems by agreeing something
>> early enough to allow it to be implemented, rather than just
>> discussing it until we run out of time.
> I thought my view on how this should be done was already clear, but just in
> case it isn't, let me restate: Enlarge the page header to make room for the
> checksum. To handle upgrades, put code in the backend to change the page
> format from old version to new one on-the-fly, as pages are read in. Because
> we're making the header larger, we need to ensure that there's room on every
> page. To do that, write a utility that you run on the cluster before running
> pg_upgrade, which moves tuples to ensure that. To ensure that the space
> doesn't get used again before upgrading, change the old version so that it
> reserves those N bytes in all new insertions and updates (I believe that
> approach has been discussed before and everyone is comfortable with
> backpatching such a change). All of this in 9.3.

This could all be done on-line if we had a per-table flag indicating
which page version is in use.  You can use some variant of CLUSTER or
VACUUM or ALTER TABLE to rewrite the table using the page version of
your choice.  This is also more granular, in that it allows checksums
(or other features) to be turned on and off on a per-table basis.
When you read the table, the same flag tells you which page version to
expect, and you can error out if you haven't got that (or if the CRCs
don't match).

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2012-02-29 19:29:26
Subject: Re: 16-bit page checksums for 9.2
Previous:From: Tom LaneDate: 2012-02-29 19:27:24
Subject: Re: controlling the location of server-side SSL files

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