Re: Release cycle length

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Release cycle length
Date: 2003-11-21 19:08:28
Message-ID: 23265.1069441708@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

Jan Wieck <JanWieck(at)Yahoo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2003-11-21 19:37:38 Re: First generic/redhatish RPM's uploaded to ftp.postgresql.org.
Previous Message Andreas Pflug 2003-11-21 19:03:44 Re: logical column position

Browse pgsql-www by date

  From Date Subject
Next Message Andrew Dunstan 2003-11-21 19:39:39 Re: Build farm
Previous Message Tom Lane 2003-11-21 18:47:48 Re: Build farm