From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prototype: In-place upgrade v02 |
Date: | 2008-09-07 13:44:02 |
Message-ID: | 48C3DAA2.2090303@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> As far as the page not fitting after conversion, what about some user
> command that will convert an entire table to the new format if page
> expansion fails.
VACUUM?
Having to run a manual command defeats the purpose somewhat, though.
Especially if you have no way of knowing on what tables it needs to be
run on.
> I am ready to focus on these issues for 8.4; all this needs to be
> fleshed out, perhaps on a wiki. As a starting point, what would be
> really nice is to start a wiki that lists all data format changes for
> every major release.
Have you looked at http://wiki.postgresql.org/wiki/In-place_upgrade
already, that Greg Smith mentioned elsewhere in this thread? That's a
good starting point.
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but AFAICS
nothing that would require scanning through relations.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-09-07 13:51:50 | Re: Prototype: In-place upgrade v02 |
Previous Message | Magnus Hagander | 2008-09-07 13:11:24 | Re: reducing statistics write overhead |