Andrew,
> This would be a very fine project for someone to pick up (maybe one of
> the corporate supporters could sponsor someone to work on it?)
We looked at it for Greenplum but just couldn't justify putting it near
the top of the priority list. The work/payoff ratio is terrible.
One justification for in-place upgrades is to be faster than
dump/reload. However, if we're assuming the possibility of new/modified
header fields which could then cause page splits on pages which are 90%
capacity, then this time savings would be on the order of no more than
50% of load time, not the 90% of load time required to justify the
programming effort involved -- especially when you take into account
needing to provide multiple conversions, e.g. 7.3-->8.1, 7.4 --> 8.1, etc.
The second reason for in-place upgrade is for large databases where the
owner does not have enough disk space for two complete copies of the
database. Again, this is not solvable; if we want in-place upgrade to
be fault-tolerant, then we need the doubled disk space anyway (you could
do a certain amount with compression, but you'd still need 150%-175%
space so it's not much help).
Overall, it would be both easier and more effective to write a Slony
automation wrapper which does the replication, population, and
switchover for you.
--Josh