Tom Lane napsal(a):
> I think we can have a notion of pre-upgrade maintenance, but it would
> have to be integrated into normal operations. For instance, if
> conversion to 8.4 requires extra free space, we'd make late releases
> of 8.3.x not only be able to force that to occur, but also tweak the
> normal code paths to maintain that minimum free space.
OK. I will focus on this. I guess this approach revival my hook patch:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00990.php
> The full concept as I understood it (dunno why Bruce left all these
> details out of his message) went like this:
>
> * Add a "format serial number" column to pg_class, and probably also
> pg_database. Rather like the frozenxid columns, this would have the
> semantics that all pages in a relation or database are known to have at
> least the specified format number.
>
> * There would actually be two serial numbers per release, at least for
> releases where pre-update prep work is involved --- for instance,
> between 8.3 and 8.4 there'd be an "8.3-and-a-half" format which is
> 8.3 but known ready to update to 8.4 (eg, enough free space available).
> Minor releases of 8.3 that appear with or subsequent to 8.4 release
> understand the "half" format number and how to upgrade to it.
I prefer to have latest processed block. InvalidBlockNumber would mean nothing
is processed and 0 means everything is already reserved. I suggest to process it
backward. It should prevent to check new extended block which will be already
correctly setup.
> * VACUUM would be empowered, in the same way as it handles frozenxid
> maintenance, to update any less-than-the-latest-version pages and then
> fix the pg_class and pg_database entries.
>
> * We could mechanically enforce that you not update until the database
> is ready for it by checking pg_database.datformatversion during
> postmaster startup.
I'm don't understand you here? Do you mean on old server version or new server
version. Or who will perform this check? Do not remember that we currently do
catalog conversion by dump and import which lost all extended information.
Thanks Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql