Re: Resurrecting pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Resurrecting pg_upgrade
Date
Msg-id 21804.1071261776@sss.pgh.pa.us
Whole thread Raw
In response to Re: Resurrecting pg_upgrade  ("Matthew T. O'Connor" <matthew@zeut.net>)
Responses Re: Resurrecting pg_upgrade
Re: Resurrecting pg_upgrade
Re: Resurrecting pg_upgrade
List pgsql-hackers
"Matthew T. O'Connor" <matthew@zeut.net> writes:
> On Fri, 2003-12-12 at 14:51, Andrew Dunstan wrote:
>> Maybe use an option which you would disable on Windows to copy the files 
>> instead of hardlinking them.

> I think this would be a good feature even without hard link problems. 
> If I am a paranoid admin, and I can afford the time and disk space
> required, I would want to keep a complete copy of my database, even
> after the new server is up and running.

That's a good point --- if the upgrade appears to work, but when you
actually start the new postmaster there's some incompatibility that
results in corruption of your user table files, then you're screwed
under a hard link approach.  Even though your old $PGDATA
directory structure is still intact, the files it contains are
corrupted.  (Even if they're not corrupt, but you hit some other
reason for backing out the update, you probably can't, because
very very soon your old WAL and clog will be irretrievably out of
date compared to the data files.)

Okay, so we want an option to copy even if we could hard link.
No problem.

Alternative thought: just recommend that if possible, people take
a filesystem dump of their old PGDATA directory after stopping
the old postmaster.  This would be sufficient for retreating to
the prior version if needed.  It might or might not be slower
than copying all the files to a new PGDATA ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Resurrecting pg_upgrade
Next
From: Manfred Spraul
Date:
Subject: Re: fsync method checking