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.
There's still nasty cases like arrays of inets, however.
I think we should try backpatching space reservations routines for a few
releases to see if we need to have these fixed parameters.
Agreed.
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.
--
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
