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

From Tom Lane
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id 8353.1330551267@sss.pgh.pa.us
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: 16-bit page checksums for 9.2  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: 16-bit page checksums for 9.2  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_upgrade --logfile option documentation
Next
From: Alvaro Herrera
Date:
Subject: Re: 16-bit page checksums for 9.2