Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore
Дата
Msg-id CAMkU=1xYD7K3u+DsH6TzDgGN4MGWCymbiczdGL8f35uqf-9xjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore  (Ken Tanzer <ken.tanzer@gmail.com>)
Ответы Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore
Список pgsql-general
Дерево обсуждения
On Thu, Jun 29, 2017 at 12:05 AM, Ken Tanzer <ken.tanzer@gmail.com> wrote:
Thanks for the responses.  For me, using the 9.2 binary was the winner.  Shoulda thought of that!

On Wed, Jun 28, 2017 at 1:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Generally speaking, it helps a lot if you don't insist on restoring the
output in a single transaction.  In this case, that would allow the
restore to ignore the new parameters and move on.

                        regards, tom lane

Well sure, I can see it increases your chances of getting _something_ restored.  But there's also a lot to be said for ensuring that _all_ your data restored, and did so correctly, no?

Record the errors, and look through them to decide if they are important or not.

But better yet, use v9.2 of pg_dump to dump things out of a 9.2 server which you want to load to another 9.2 server.  Don't be at the mercy of your $PATH.

(Or even more better yet, upgrade the servers from 9.2 to 9.6, and then use 9.6's pg_dump)

Cheers,

Jeff

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

Предыдущее
От: Mikhail
Дата:
Сообщение: [GENERAL] [GENERAL] Significant discrepancy in index cost estimation
Следующее
От: DrakoRod
Дата:
Сообщение: Re: [GENERAL] postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting