Re: [PATCH] Space reservation v02

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