Re: Resurrecting pg_upgrade

Поиск
Список
Период
Сортировка
От Thomas Swan
Тема Re: Resurrecting pg_upgrade
Дата
Msg-id 3FDA2FB9.1070307@idigx.com
обсуждение исходный текст
Ответ на Re: Resurrecting pg_upgrade  ("Matthew T. O'Connor" <matthew@zeut.net>)
Ответы Re: Resurrecting pg_upgrade  (Dave Smith <dave.smith@candata.com>)
Список pgsql-hackers
Matthew T. O'Connor wrote:

>On Fri, 2003-12-12 at 15:42, Tom Lane wrote:
>  
>
>>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 ...
>>    
>>
>
>Certainly the easier path code wise :-)  Being the belt, suspenders and
>steel tip boots (foot gun protection) type that I am, I would make a
>backup even if pg_upgrade copies all the data files.  Having pg_upgrade
>copy the data files give you an extra layer of protection if desired,
>and can possibly save an admin who fails to get a good backup of the old
>PGDATA for what ever reason.  
>
>  
>
I'd be in favor of a prompt at the beginning of the script.  "Have made
a copy of the PGDATA directory?"  If answered no, then ask for a
confirmation to proceed without backup?  To skip the prompt have an
option for '--skip-prompt' for those who are a little more sure of
themselves or want to write a more automated script for this process.

This approach gives more flexibility as there may not be sufficient
storage available for double the existing database size for conversion
on that mount point / disk.  The admin doing the upgrade can copy the
existing database wherever they need it: tape, another filesystem, NFS
mount, etc.

--
Thomas Swan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Matthew T. O'Connor"
Дата:
Сообщение: Re: Resurrecting pg_upgrade
Следующее
От: Tom Lane
Дата:
Сообщение: Re: fsync method checking