Re: [PATCH] Space reservation v02 - Mailing list pgsql-hackers

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?

> > 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.

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.

But again, all this is trying to handle cases where the data size
increases, which is a rare event for us.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +