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".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
