Tom Lane napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Adding catalog columns seems rather complicated, and not back-patchable.
Agreed, we'd not be able to make them retroactively appear in 8.3.
I imagined that you would have just a single cluster-wide variable, a
GUC perhaps, indicating how much space should be reserved by
updates/inserts. Then you'd have an additional program, perhaps a new
contrib module, that sets the variable to the right value for the
version you're upgrading, and scans through all tables, moving tuples so
that every page has enough free space for the upgrade. After that's
done, it'd set a flag in the data directory indicating that the cluster
is ready for upgrade.
Possibly that could work. The main thing is to have a way of being sure
that the prep work has been completed on every page of the database.
The disadvantage of not having catalog support is that you'd have to
complete the entire scan operation in one go to be sure you'd hit
everything.
I prefer to have catalog support. Special on very long tables it helps when
somebody stop preupgrade script for some reason.
Another thought here is that I don't think we are yet committed to any
changes that require extra space between 8.3 and 8.4, are we? The
proposed addition of CRC words could be put off to 8.5, for instance.
So it seems at least within reach to not require any preparatory steps
for 8.3-to-8.4, and put the infrastructure in place now to support such
steps in future go-rounds.
Yeah. We still have V4 without any storage modification (exclude HASH index).
However I think if reloptions will be use for storing information about reserved
space then It shouldn't be a problem. But we need to be sure if it is possible.
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
