Re: pg_migrator issue with contrib

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_migrator issue with contrib
Дата
Msg-id 200906081518.n58FIed05377@momjian.us
обсуждение исходный текст
Ответ на Re: pg_migrator issue with contrib  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список pgsql-hackers
Dimitri Fontaine wrote:
> >> I don't think that anything in that line is going to be helpful.
> >> What it will lead to is people mindlessly using --force (cf our
> >> bad experiences with -i for pg_dump).  If you can't give a *useful*
> >> ie trustworthy warning/error, issuing a useless one is not a good
> >> substitute.
> >
> > Well, in that case, error out would be a better option than doing it and
> > probably fail later. And have a --force option available, but don't
> > suggest it.
> 
> My vote would go to detect and error out without recovering option. If
> the tool is not able to handle a situation and knows it, I don't see
> what would be good about it leting the user lose data on purpose.
> 
> The --force option should be for the user to manually drop his columns
> and indexes (etc) and try pg_migrator again, which will stop listing
> faulty objects but care about the now compatible cluster.
> 
> Restoring the lost data is not the job of pg_migrator, of course.

Agreed.  Right now pg_migrator never modifies the old cluster except for
renaming pg_control (documented) so the old cluster is not accidentally
restarted.  I don't want to change that behavior.

I would filter the dump --schema file, but again, it is best to let the
administrator do it, and if they can't, they should just do
dump/restore.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: pg_migrator issue with contrib
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_migrator issue with contrib