Re: 7.1 Release Date

* Brook Milligan <brook@biology.nmsu.edu> [000829 12:07] wrote:
>    We NEED this 'pg_upgrade'-on-steroids program that simply Does The Right
>    Thing.
>
>    I think it's high time that the dump/initdb/restore cycle needs to be
>    retired as a normal upgrading step.
>
> YOU (i.e., people relying on the RH stuff to do everything at once)
> may need such a thing, but it seems like you are overstating the case
> just a bit.  If this project gets adopted by core developers, it would
> seem to conflict drastically with the goal of developing the core
> functionality.  Thus, it's not quite "high time" for this.
>
> There is nothing inherently different (other than implementation
> details) about the basic procedure for upgrading the database as
> compared to upgrading user data of any sort.  In each case, you need
> to go through the steps of 1) dump data to a secure place, 2) destroy
> the old stuff, 3) add new stuff, and 4) restore the old data.  In the
> case of "normal" user data (home directories and such) the
> dump/restore sequence can be performed using exactly those commands or
> tar or dd or whatever.  In the case of the database we have the
> pg_dump/psql commands.  In either case, the person doing the upgrade
> must have enough of a clue to have made an appropriate dump in the
> first place before trashing their system.  If the person lacks such a
> clue, the solution is education (e.g., make the analogy explicit, show
> the tools required, make pg_dump more robust, ...) not redirecting the
> precious resources of core developers to duplicate the database system
> in a standalone program for upgrades.

Actually you make the process sound way too evil, a slightly more
complex system can leave you fully operational if anything goes wrong:

install new postgresql
start new version on alternate port
suspend updating data (but not queries)
do a direct pg_dump into the new version
       (i think you need to export PG_PORT to use the alternate port)
suspend all queries
shutdown old version
restart new version on default port
resume queries

if (problems == 0) {
  resume updates;
} else {
  stop updates and queries;
  shutdown new
  restart old
  resume normal operations
}

Ok, it's a LOT more complex, but with careful planning pain may be
kept to an acceptable minimum.

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."