To: Jan Wieck <JanWieck@Yahoo.com>
Cc: Alvaro Herrera <alvherre@dcc.uchile.cl>,
	Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	Peter Eisentraut <peter_e@gmx.net>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Release cycle length 
In-reply-to: <3FBE5A46.4090102@Yahoo.com> 
References: <Pine.LNX.4.44.0311180038310.639-100000@peter.localdomain>
	<20031117202346.M731@ganymede.hub.org>
	<3FBB7F20.8050005@Yahoo.com> <6400.1069359578@sss.pgh.pa.us>
	<3FBD6CAA.7040500@familyhealth.com.au>
	<20031121130359.GE26392@dcc.uchile.cl> <3FBE5A46.4090102@Yahoo.com>
Comments: In-reply-to Jan Wieck <JanWieck@Yahoo.com>
	message dated "Fri, 21 Nov 2003 13:32:38 -0500"
Date: Fri, 21 Nov 2003 14:08:28 -0500
Message-ID: <23265.1069441708@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jan Wieck <JanWieck@Yahoo.com> writes:
> Alvaro Herrera wrote:
>> One of the most complex would be to avoid the need of pg_dump for
>> upgrades ...

> We don't need a simple way, we need a way to create some sort of catalog 
> diff and "a safe" way to apply that to an existing installation during 
> the upgrade.

I still think that pg_upgrade is the right idea: load a schema dump from
the old database into the new one, then transfer the user data files and
indexes via cheating (doubly linking, if possible).  Obviously there is
a lot of work still to make this happen reliably, but we have seen
proof-of-concept some while ago, whereas "catalog diffs" are pie in the
sky IMHO.  (You could not use either the old postmaster version or the
new version to apply such a diff...)

A big advantage of the pg_upgrade concept in my mind is that if it fails
partway through, you need have made no changes to the original
installation.  Any mid-course problem with an in-place-diff approach
leaves you completely screwed :-(

			regards, tom lane