Thread: Migrating from 32 to 64 bit

Hi,

I'm currently setting up 2 new servers to act as a PgSQL cluster (8.2).

This basically consists in the reinstallation of the OS (64Bit).

Question:
I'd like to know if it is possible (and wise) to just keep the
/var/lib/postgres...... directories from the old 32Bit server to use on
the 64Bit version.

This is just as a personal interest since I can also just dump and
restore the database in about 2.5 hrs.

Thanks

Laurent

Laurent CARON wrote:
> Question:
> I'd like to know if it is possible (and wise) to just keep the
> /var/lib/postgres...... directories from the old 32Bit server to use on
> the 64Bit version.
>
> This is just as a personal interest since I can also just dump and
> restore the database in about 2.5 hrs.

Dump and restore. Using the old data dirs won't work.


--
Best regards,
Hannes Dorbath

Laurent CARON wrote:
> Question:
> I'd like to know if it is possible (and wise) to just keep the
> /var/lib/postgres...... directories from the old 32Bit server to use on
> the 64Bit version.
>
> This is just as a personal interest since I can also just dump and
> restore the database in about 2.5 hrs.

Dump and restore. Using the old data dirs won't work.


--
Best regards,
Hannes Dorbath

But theoretically speaking, 32 or 64-bit ness of the application (ie the postmaster server) should not influence the data types offered by a particular DB version. That is the semantics of data types and cpu-arch (register width, big endian, little endian, sparc, mips, x86), etc ) offered by a particular DB version should be orthogonal.

A practical example is when I first begin my business on a Mac, then I move the database to a Sun and then on to a mainframe....

Cheers
Medi

montaseri@gmail.com ("Medi Montaseri") writes:
> But theoretically speaking, 32 or 64-bit ness of the application (ie the postmaster server) should not influence the
datatypes offered by a particular DB 
> version. That is the semantics of data types and cpu-arch (register width, big endian, little endian, sparc, mips,
x86),etc ) offered by a particular DB 
> version should be orthogonal.
> A practical example is when I first begin my business on a Mac, then I move the database to a Sun and then on to a
mainframe....

That's well and fine, but the point is that when those (reasonably
generic!) data types get compiled into code for a particular platform,
with particular endianness and word size, how it is optimal to
represent them will vary based on the characteristics of the platform.

As a result, not only do you need different executable binaries each
platform, but you also need different binary database structures on
each platform.

A conceptually mitigating factor should be that by the time you get
around to changing platforms, there will likely be a Newer, Better,
Major PostgreSQL version available.  So you should be considering
doing a migration from "old, slower, inferior version on the inferior
platform" to the "better, stronger, faster version on the superior
platform."  With THAT context, the need to run initdb is further
"given."
--
output = ("cbbrowne" "@" "linuxdatabases.info")
http://www3.sympatico.ca/cbbrowne/x.html
"Have  you noticed   that,  when we were   young,  we were   told that
`everybody else   is doing  it' was   a  really  stupid reason  to  do
something,  but now it's the standard  reason for picking a particular
software package?" -- Barry Gehm

I agree with you practical points....I qualified my comments by saying....theoretically speaking....

Cheers
Medi