On 24/09/2010 8:40 PM, Raymond O'Donnell wrote:
> On 24/09/2010 13:21, kongsgar@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/