Re: How to restore from backup to 8.4.3 server using 9.0 dump/restore

Le 15/12/2010 17:26, Adrian Klaver a écrit :
> On 12/15/2010 07:34 AM, Andrus Moor wrote:
>>> No, this is just pilot error. Any version of pg_dump will produce
>>> output that is meant to be loaded into the matching server version
>>> (or a later version). If you are intending to load back into 8.4,
>>> use the 8.4 pg_dump.
>>>
>>> You may have been reading the recommendation to use the later version's
>>> pg_dump when dumping an older server to perform an upgrade. It's good
>>> advice, but only for upgrades.
>>
>> Windows application needs to support backup/restore for all servers >=8
>> between same server version.
>> So it must distibute 8.0, 8.1, 8.2, 8.3, 8.4, 9.0 pg_dump/pg_restore
>> with application,
>> including all VC++ runtime versions and all dlls specific to this
>> version and invoke
>> specific pg_dump/pg_restore depending on server version ?
>
> No it only needs to use the pg_dump/pg_restore that exist for each Pg
> instance.
>
>>
>> Do you really think that this is reasonable ?
>> I'nt there a simpler way ?
>>
>> I havent seen that pg_admin includes every pg_dump / pg_restore version.
>
> I don't use pgAdmin so I am flying blind here, but I guess they use some
> variation of what I suggest above.
>

pgAdmin has the same issue. If you use the pg_dump distributed with
pgAdmin 1.12 to backup a 8.4 PostgreSQL server, you won't be able (or
have difficulties) to restore it on the 8.4 server. Or IOW, you're screwed.

That's why you can change the binaries or change the location, where the
binairies are found, in the options dialog.

And we don't distribute each pg_dump/pg_dumpall/pg_restore releases. It
would make the package so much bigger it isn't really worth it. Anyway,
even if we did, the UI can't choose the right release to use because it
would need to know on which release you want to restore it. Meaning that
the user would need to change the target release. Meaning he should
understand the issue underneath.

My whole point it that there is no best way to handle this, and probably
no good one either.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com