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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
