Re: changing the endianness of a database

On May 12, 2008, at 4:02 PM, Chris Saldanha wrote:

> Hi,
>
> We'd like to ship PostgreSQL as part of a product that runs on both
> PPC and
> Intel Macs, but the database files are tied to the build settings and
> endianness of the computer that the database was initialized on.
>
> Is there any way to cause the server to modify the database files in-
> place
> for endianness issues?  I know that a backup-then-restore process
> would fix
> the data, but on Macs, many users use Apple's computer migration
> tools to
> copy all their programs/data/users/etc.. to new Macs.
>
> If the user moves from a PPC to an Intel Mac, for instance, the
> database
> would be copied over, but the data would be for the old computer,
> and the
> database won't start.  The backup/restore process is hard for end
> users,
> since they don't understand it -- and they won't contact us until
> after the
> migration is done, and often not until they've discarded the old
> computer.
>
> It would be nice if there was a way to recover the data from the
> existing
> database files.
>
> I found this old thread on a related topic, and it seems that this
> cannot be
> done...
> http://archives.postgresql.org/pgsql-general/2008-01/msg00635.php

You know that you don't have to compile postgresql as "Universal",
right? If you have separate PPC and Intel versions (not lipo'd
together), then, presumably, you should be able to figure out which
one needs to run. The PPC postgresql would then run on the Macintel
under Rosetta and you would then have control to proceed with an
automatic dump/restore. However, this would not work for someone
moving the database from an Intel machine to a PPC machine.

Postgresql is simply not well-suited for such uncontrolled
environments. What happens when you upgrade postgresql? Do you then
ship with 4 version of the db (Intel/PPC * 8.2/83)? Perhaps you should
dump all the non-transient data whenever the application is shut down
(in anticipation of an upgrade)?

Cheers,
M