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
