Re: Resurrecting pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Resurrecting pg_upgrade
Дата
Msg-id 21804.1071261776@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Resurrecting pg_upgrade  ("Matthew T. O'Connor" <matthew@zeut.net>)
Ответы Re: Resurrecting pg_upgrade  ("Matthew T. O'Connor" <matthew@zeut.net>)
Re: Resurrecting pg_upgrade  ("Marc G. Fournier" <scrappy@postgresql.org>)
Re: Resurrecting pg_upgrade  ("Sander Steffann" <steffann@nederland.net>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Resurrecting pg_upgrade
Следующее
От: Manfred Spraul
Дата:
Сообщение: Re: fsync method checking