Thread: pg_dump from older version and pg_restore in newer
Hi,
I am planning a migration from 9.1.7 to 9.4.0.
On many threads I noticed that the recommendation is “Be sure to use pg_dump from the *new* version to take the dump from the old database.”
Is that a must?
Is there a chance that a restore using new version will fail because the dump was taken with *old* bin?
Regards
Hemy
Hi,
I am planning a migration from 9.1.7 to 9.4.0.
On many threads I noticed that the recommendation is “Be sure to use pg_dump from the *new* version to take the dump from the old database.”
Is that a must?
Is there a chance that a restore using new version will fail because the dump was taken with *old* bin?
Regards
Hemy
Aitla, thank you very much for the prompt reply!
The fact that I saw this sentence “Be sure to use pg_dump from the *new* version to take the dump from the old database.” more than once made me wonder if I am not missing something.
Thanks
Hemy
From: Shreeyansh dba [mailto:shreeyansh2014@gmail.com]
Sent: 18 January 2015 13:03
To: Perry, Hemy
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] pg_dump from older version and pg_restore in newer
On Sun, Jan 18, 2015 at 3:55 PM, Perry, Hemy <hemy_perry@mentor.com> wrote:
Hi,
I am planning a migration from 9.1.7 to 9.4.0.
On many threads I noticed that the recommendation is “Be sure to use pg_dump from the *new* version to take the dump from the old database.”
Is that a must?
Is there a chance that a restore using new version will fail because the dump was taken with *old* bin?
Regards
Hemy
Hi Hemy,
Using of new version dump is not a must. You can use dump of Older version(9.1.7) and use restore of New version(9.4.0)
Using restore of new version will not fail because the dump was taken with *old* bin.
This can fail only if you give any wrong syntax in command.
Hope this clears your issue.
-
Thanks & Regards,
Venkataramana Aitla
Database Administrator
On Jan 18, 2015, at 3:25 AM, Perry, Hemy <hemy_perry@mentor.com> wrote: > > Is that a must? No. Just a good precaution. > Is there a chance that a restore using new version will fail because the dump was taken with *old* bin? Yes. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice
Scott Ribe <scott_ribe@elevated-dev.com> writes:
> On Jan 18, 2015, at 3:25 AM, Perry, Hemy <hemy_perry@mentor.com> wrote:
>> Is that a must?
> No. Just a good precaution.
>> Is there a chance that a restore using new version will fail because the dump was taken with *old* bin?
> Yes.
In principle, ie in the absence of bugs, it should work either way.
The reason for the standard recommendation to use the newer version's
pg_dump is the possibility that your old pg_dump contains bugs that have
been fixed in the newer version. This is a non-negligible risk when
you're talking about a pg_dump that's several years old, as 9.1.7 is.
If you were comparing minor releases of similar date, eg 9.1.14 versus
9.4.0, the risk calculation might shift the other way (since 9.1.14 would
contain back-patches for any old bugs recently identified, but 9.4.0 might
contain new bugs all its very own).
If you're worried about compatibility issues, a reasonably quick and
reliable way of pre-testing is to do a "pg_dump -s" (schema only) and
see if that loads into the new version without issues.
regards, tom lane
On Jan 18, 2015, at 12:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > In principle, ie in the absence of bugs, it should work either way. ... > The reason for the standard recommendation to use the newer version's > pg_dump is the possibility that your old pg_dump contains bugs that have > been fixed in the newer version. This is a non-negligible risk when > you're talking about a pg_dump that's several years old, as 9.1.7 is. > If you were comparing minor releases of similar date, eg 9.1.14 versus > 9.4.0, the risk calculation might shift the other way... Yep. I didn't want to say it out loud in the prior post, but I don't think I have ever actually used the new dump on theold db. Then again, I'm almost never more than 1 point release behind, so my way of doing things is not generally applicable;-) -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice