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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
