Re: changing the endianness of a database

From: Shane Ambler <pgsql(at)Sheeky(dot)Biz>
To: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: changing the endianness of a database
Date: 2008-05-12 23:36:07
Message-ID: 4828D467.9050202@Sheeky.Biz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

A.M. wrote:

> 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.

That would be my suggestion - run a ppc version to dump then restore
with an intel version. Maybe a startup script can detect when to do this.

Maybe this is an argument against making universal postgres binaries.

> 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)?

As far as upgrades that could/should be handled in the installer script.
Dump from the installed version then install the new one and restore.
That is - using Apple's installer setup.

--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Vic Simkus 2008-05-13 00:17:22 Re: Recovering database after disk crash
Previous Message Tom Lane 2008-05-12 23:16:03 Re: Recovering database after disk crash