Re: 16-bit page checksums for 9.2

On 2/29/12 3:53 PM, Alvaro Herrera wrote:
>
> Excerpts from Tom Lane's message of mié feb 29 18:34:27 -0300 2012:
>>
>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>> On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
>>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>>> The utility would run in the old cluster before upgrading, so the the flag
>>>> would have to be present in the old version. pg_upgrade would check that the
>>>> flag is set, refusing to upgrade if it isn't, with an error like "please run
>>>> pre-upgrade utility first".
>>
>>> I find that a pretty unappealing design; it seems to me it'd be much
>>> easier to make the new cluster cope with everything.
>>
>> Easier for who? I don't care for the idea of code that has to cope with
>> two page formats, or before long N page formats, because if we don't
>> have some mechanism like this then we will never be able to decide that
>> an old data format is safely dead.
>
> .. 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.

Page checksuming is something a lot of people (myself included) want to see. Being able to get it in 9.2 would be a big win over crossing our fingers that at some point in the future (who knows when) we'll maybe figure out the page format upgrade issue. While we should definitely be looking into that issue it's definitely not going to get fixed in 9.2. ISTM that checksums are actually ready to go if people can just swallow the bitter pill of a screwed-up page version field until we can actually get an upgrade utility in place (and until we get that utility in place I don't see that the version field would do us any good anyway...)
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net