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