Re: pg_migrator to /contrib in a later 9.0 beta

<crazy hat on --- but do I ever quit it?>

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> We need to be thinking more now about such a contingency. Postgres use in
> very large installations is now at such a level that requiring a
> pg_dump/pg_restore is really not an option for many users. If pg_migrator is
> not always going to work then we need to be addressing that now, or else it
> is at best a stop-gap. ISTM some sort of page layout versioning scheme might
> be at least part of what we'll need in the medium term.

Would it be on the same complexity level to support recovering WALs from
previous version? On the code maintenance alone it sounds bad enough,
but apart from that?

The idea of course would be then to add an Hot-Standby server running
next PostgreSQL version and fed from current production server. The base
backup would have to either be processed by pg_migrator or we'd have to
open the possibility of starting a slave from a pg_dump, which has been
talked about already. The change here would be that this initial step
would not be done as part of the maintenance window.

Now you tell me how awful this idea really is :)

Regards,
--
dim