Re: [WIP] In-place upgrade

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