From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Space reservation v02 |
Date: | 2009-01-30 06:16:07 |
Message-ID: | 49829B27.2000402@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2009-01-30 08:03:22 | Re: mingw check hung |
Previous Message | Greg Smith | 2009-01-30 05:34:17 | Re: [PATCH] Space reservation v02 |