On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 29.02.2012 21:30, Robert Haas wrote: >> >> On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera >> <alvhe...@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".
I find that a pretty unappealing design; it seems to me it'd be much easier to make the new cluster cope with everything. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
