Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore - Mailing list pgsql-general

From Jeff Janes
Subject Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore
Date
Msg-id CAMkU=1xYD7K3u+DsH6TzDgGN4MGWCymbiczdGL8f35uqf-9xjw@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore  (Ken Tanzer <ken.tanzer@gmail.com>)
Responses Re: [GENERAL] 9.6 parameters messing up my 9.2 pg_dump/pg_restore
List 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 by date:

Previous
From: Mikhail
Date:
Subject: [GENERAL] [GENERAL] Significant discrepancy in index cost estimation
Next
From: DrakoRod
Date:
Subject: Re: [GENERAL] postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting