Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
> Heikki Linnakangas wrote:
> > Bruce Momjian wrote:
> > > The patch has two space reservations, one per page, another per tuple.
> > > Now, thinking back, what types of changes have we made that increase
> > > storage size. The one that I can think of first is where we made a data
> > > type require larger storage. (I think inet/cidr.) This could not be
> > > handled by this patch because if a row had _two_ values of that type,
> > > there would be no way to specify this using the two supplied parameters.
> >
> > Well, I believe the idea was that the pre-upgrade script that sets the
> > space reservation would look at the catalogs to decide the right
> > reservation for each table.
>
> Interesting --- so you set the reservation per table --- that seems much
> better than a GUC, certainly. I assume we would still need a per-page
> GUC that affects all tables? Or one for heap and one for index pages?
Each access methods has different requirements and it heavily depends on
specific relations. Also TOAST tables has different requirements. GUC
variable is not good option.
> > > One thing I think would help would be a pg_class column that says
> > > whether the table is ready for upgrading. This is something we can't
> > > easily backpatch and would be helpful so people could do their upgrade
> > > preparation in a staged manner, rather than having to do it all at once,
> > > and would give the upgrade scripts confidence that the backpatch had
> > > done everying needed. The backpatched code would set this pg_class
> > > column value when it was done making sure the table is ready for upgrade
> > > (probably via vacuum). I recommend an int2 column to store
> > > PG_VERSION_NUM / 100.
> >
> > I think that being able to stop and restart the pre-upgrade process is a
> > luxury we can add later. Also note that the pre-upgrade tool can use a
> > flat file in the data directory to store state in a more free-form
> > fashion. To implement restartability, for example, you could dump a list
> > of relfilenodes not yet scanned to the file at start, and strike them
> > out as you go.
>
> Well, I was thinking the new pg_class column would allow the upgrade to
> verify the pre-upgrade script was run properly, but a flat file works
> just as well if we assume we are going to pre-upgrade in one pass.
Flat file or special table for pg_upgrade will work fine.
> However, I am afraid requiring this pre-upgrade to run while the server
> is basically in single-user mode will make upgrade-in-place be a long
> process for many users, and if it takes a significant time compared to
> dump/reload, they might as well dump/reload.
pre_upgrade script should be run during normal operation. There will be
some limitation. For example CREATE/ALTER TABLE can cause problems.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
