Re: 9.6 parameters messing up my 9.2 pg_dump/pg_restore

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: 9.6 parameters messing up my 9.2 pg_dump/pg_restore
Date: 2017-06-29 16:34:02
Message-ID: CAMkU=1xYD7K3u+DsH6TzDgGN4MGWCymbiczdGL8f35uqf-9xjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jun 29, 2017 at 12:05 AM, Ken Tanzer <ken(dot)tanzer(at)gmail(dot)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(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message DrakoRod 2017-06-29 17:03:00 Re: postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting
Previous Message Mikhail 2017-06-29 16:21:13 [GENERAL] Significant discrepancy in index cost estimation