From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Resurrecting pg_upgrade |
Date: | 2003-12-12 20:42:56 |
Message-ID: | 21804.1071261776@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Matthew T. O'Connor" <matthew(at)zeut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Spraul | 2003-12-12 20:54:34 | Re: [HACKERS] fsync method checking |
Previous Message | Andrew Dunstan | 2003-12-12 20:40:06 | Re: Resurrecting pg_upgrade |