Re: [HACKERS] PGUpgrade WAS: Audio interview

On Feb 8, 2006, at 12:55 PM, Josh Berkus wrote:

> 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.

I just posted an idea for first upgrading a physical backup of the
data directory that you would create when doing "Online backups" and
then also altering the the WAL log records as they are applied during
recovery. That way the actual load time might still be huge but
since it could run in parallel with the running server it would
probably eliminate 99% of the downtime. Would that be worth the effort?

Also all the heavy lifting could be offloaded to a separate box while
your production server just keeps running unaffected.

> 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).

Yeah, anyone who has so much data that they need this feature but
isn't willing to back it up is crazy. Plus disk space is cheap.

> Overall, it would be both easier and more effective to write a
> Slony automation wrapper which does the replication, population,
> and switchover for you.

Now that is something that I would actually use. I think that a
little bit of automation would greatly enhance the number of users
using slony.

Rick