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

Re: 16-bit page checksums for 9.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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 <david(at)fetter(dot)org>, aidan <aidan(at)highrise(dot)ca>, stark <stark(at)mit(dot)edu>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 16-bit page checksums for 9.2
Date: 2012-03-01 00:48:47
Message-ID: 653.1330562927@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Jim Nasby <jim(at)nasby(dot)net> writes:
> On 2/29/12 3:53 PM, Alvaro Herrera wrote:
>> .. in fact this is precisely what killed Zdenek Kotala's idea of
>> upgrading.

> This is also why Simon has avoided the whole upgrade thing with his 16 bit checksum idea (otherwise presumably we'd be looking at bigger checksums anyway).

> I get that fussing around with the version field is ugly. If there was another way to do this without breaking pg_upgrade then it would be silly to mess with the version field. Unfortunately, there is no other way.

Fundamentally, what is going on here is that several of us think that we
need a page format upgrade infrastructure first, and then we can think
about adding checksums.  Simon would like to cram checksums in without
building such infrastructure, regardless of the consequences in code
ugliness or future maintainability.  Personally, I think that is a bad
tradeoff.  Eventually we are going to have to build that infrastructure,
and the more we've kluged the page header format in the meanwhile, the
more unpleasant it's going to be.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-03-01 02:39:53
Subject: Re: Client Messages
Previous:From: Alvaro HerreraDate: 2012-03-01 00:48:27
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

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