Tom Lane napsal(a):
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 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