Heikki Linnakangas wrote:
> 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.
My assumption is that the page not fitting would be a rare case so
requiring something like vacuum to fix it would be OK.
What I don't want to do it to add lots of complexity to the code just to
handle the page expansion case, when such a case is rare and perhaps can
be fixed by a vacuum.
> > 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.
Agreed.
> 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.
Yep.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
