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

From Heikki Linnakangas
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id 4F4E7D88.7090004@enterprisedb.com
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
List pgsql-hackers
On 29.02.2012 21:30, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
> <alvherre@commandprompt.com>  wrote:
>> Note that if we want such an utility to walk and transform pages, we
>> probably need a marker in the catalogs somewhere so that pg_upgrade can
>> make sure that it was done in all candidate tables -- which is something
>> that we should get in 9.2 so that it can be used in 9.3.  Such a marker
>> would also allow us get rid of HEAP_MOVED_IN and HEAP_MOVED_OUT.
>
> Getting rid of HEAP_MOVED_IN and HEAP_MOVED_OUT would be really nice,
> but I don't see why we need to squeeze anything into 9.2 for any of
> this.  pg_upgrade can certainly handle the addition of a new pg_class
> column, and can arrange for in-place upgrades from pre-9.3 versions to
> 9.3 to set the flag to the appropriate value.

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".

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: "make check" in src/test/isolation is unworkable
Next
From: Peter Eisentraut
Date:
Subject: Re: controlling the location of server-side SSL files