Re: Release cycle length
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2003-11-21T19:08:28Z
Lists: pgsql-hackers
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