On 24/09/2010 8:40 PM, Raymond O'Donnell wrote:
On 24/09/2010 13:21, kongs...@stud.ntnu.no wrote:
What version of PG was it?
The "PG_VERSION" file = 8.3
OK, well at least it's not an ancient version that's not available any
more. :-)
As Craig said, the best thing is to get hold of a copy of 8.3 that
matches the architecture of the old server machine
Or compile one, if necessary. You should *certainly* compile one in
preference to trying to hack outdated packages onto your new system by
force, as some people seem to do. *BAD* *IDEA*, do not try it. Just by
way of warning.
If you do compile it, specify a non-default --prefix that's a unique new
subtree, so you can just "rm -rf" it when you're done with it. Think
--prefix=/opt/pgsql8.3 . If you install it directly into /usr/local
you'll have a crufty old libpq and headers hanging around later.
Personally, if I were facing this situation I'd fire up a virtual
machine with the right architecture and give it access to my old data
dir instead. Much less hassle, as I can just drop the VM once I'm done
with it, and my real host's software loadout and configuration are
unaffected. With kvm (+virt-manager if you want) making it so trivial to
create and destroy VMs this is a no-brainer. You can run a 32-bit VM on
a 64-bit (Intel/AMD) host just fine, so if you're transitioning from 32-
to 64-bit you shouldn't have any issues.
You could always install the old Pg locally on the new host, from
packages or by compiling it, but I wouldn't recommend it. Use a VM if
you can, keep things clean.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
