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
