Thread: dump/restore needed when switching from 32bit to 64bit processor architecture?

Hi,

when have a 8.0.3 database running on a XEON machine. We want to replace
it with an Opteron where postgresql is to be compiled with 64bit. Do we
need a dump/restore or can we just start the db with the new compilation?

Regards,

Dirk

=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <lutzeb@aeccom.com> writes:
> when have a 8.0.3 database running on a XEON machine. We want to replace
> it with an Opteron where postgresql is to be compiled with 64bit. Do we
> need a dump/restore or can we just start the db with the new compilation?

I'd bet you need a dump/restore --- MAXALIGN is most likely different
on the two platforms.  If it isn't, then maybe you could get away with
this, but it's definitely risky.

            regards, tom lane

Thanks Tom,

we now stay with 32bit to allow backward compatibilty with XEON which is needed as a fail-over system.

The question is which gcc cflags are best used with XEON and Opteron to achieve fail-over compatibility. This is what we used for postgresql 8.0.3:

XEON, RHEL 3.0 AS:
    CFLAGS = "-mcpu=pentium4 -march=pentium4"

Opteron 875, RHEL 3.0 AS,  gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42):
    CFLAGS = "-Acpu=x86_64 -Amachine=x86_64"

Do we still need a dump/restore with this config?

Regards,

Dirk


Tom Lane wrote:

Dirk Lutzebäck <lutzeb@aeccom.com> writes: 

when have a 8.0.3 database running on a XEON machine. We want to replace 
it with an Opteron where postgresql is to be compiled with 64bit. Do we 
need a dump/restore or can we just start the db with the new compilation?   

I'd bet you need a dump/restore --- MAXALIGN is most likely different
on the two platforms.  If it isn't, then maybe you could get away with
this, but it's definitely risky.
		regards, tom lane 

Dirk Lutzebäck wrote:
> The question is which gcc cflags are best used with XEON and Opteron
> to achieve fail-over compatibility.

Configure both ways and run a diff over the generated pg_config.h files.
If there are differences, then there's a potential for trouble.  (No
differences don't say there won't be trouble, but it'd be far less
likely.)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/