Re: [PATCH] Space reservation v02

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +