PiTR and other architectures....

Philip Warner wrote:

Having just tried to restore a 64 bit BSD database to a 32 bit linux
machine (using PiTR), I have now realized the (with hindsight, obvious)
error in my ways.

Now, I need to plan a way forward. From reading of other peoples similar
problems, I now realize that I need a system with identical on-disk
formats. Question is:

Is there a simple way to determine compatibility? (eg. a small
well-defined list of requirements)

initdb on one platform, copy the data directory over to the other
system, and try to start postmaster. It will complain if the on-disk
format is not compatible.

You can also run pg_controlinfo on both systems, and compare the
results. If the "Maximum data alignment", and all the values below it in
the pg_controlinfo output match, the formats are compatible.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:

You can also run pg_controlinfo on both systems, and compare the
results. If the "Maximum data alignment", and all the values below it
in the pg_controlinfo output match, the formats are compatible.

s/pg_controlinfo/pg_controldata/

cheers

andrew

On Tue, 2008-12-02 at 16:21 +0200, Heikki Linnakangas wrote:

initdb on one platform, copy the data directory over to the other
system, and try to start postmaster. It will complain if the on-disk
format is not compatible.

You can also run pg_controlinfo on both systems, and compare the
results. If the "Maximum data alignment", and all the values below it in
the pg_controlinfo output match, the formats are compatible.

I don't think these things will work for all differences that could be
problematic. For instance, a GNU system has a different collation for
the en_US locale than an OS X system. This means that the indexes built
using en_US on one system can't be moved to the other.

How would either of these tests be able to determine that the systems
are incompatible?

I don't think this is a problem between GNU and FreeBSD, however, so
this may work in Philip's case.

Regards,
Jeff Davis

On Tue, 2008-12-02 at 23:02 +1100, Philip Warner wrote:

In the specific instance I am working with, I'd like to copy from 64
bit AMD BSD system to a 64 bit Linux system.

I wouldn't recommend it. Midnight is the wrong time to find out that
there was a difference that mattered after all. Is the risk worth it?

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Jeff Davis wrote:

On Tue, 2008-12-02 at 16:21 +0200, Heikki Linnakangas wrote:

initdb on one platform, copy the data directory over to the other
system, and try to start postmaster. It will complain if the on-disk
format is not compatible.

You can also run pg_controlinfo on both systems, and compare the
results. If the "Maximum data alignment", and all the values below it in
the pg_controlinfo output match, the formats are compatible.

I don't think these things will work for all differences that could be
problematic. For instance, a GNU system has a different collation for
the en_US locale than an OS X system. This means that the indexes built
using en_US on one system can't be moved to the other.

How would either of these tests be able to determine that the systems
are incompatible?

wow...that's a little scary. Sounds like there is no trustworthy test I
can run. Other than the case of collation differences, are there any
other kinds of problems that would not be detected by even a postmaster
restart?

|/

On Wed, 2008-12-03 at 10:15 +1100, Philip Warner wrote:

wow...that's a little scary. Sounds like there is no trustworthy test I
can run. Other than the case of collation differences, are there any
other kinds of problems that would not be detected by even a postmaster
restart?

I can't answer that question authoritatively. If the locales obey the
same rules, and pg_controldata has the same output for the relevant
values (as Heikki mentioned), I *think* it will work.

But, as Simon pointed out, is it really worth the risk? PITR is closer
to a physical process, and it's probably wise to just assume it's not
portable.

Regards,
Jeff Davis

But, as Simon pointed out, is it really worth the risk? PITR is closer
to a physical process, and it's probably wise to just assume it's not
portable.

Yeah...I am getting that impression ;-). From this I will assume we need:

- same OS (and OS minor version?)
- same CPU architecture

I was hoping it was a simple set of requirements, but that's life.

--
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 03 5330 3171 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
http://www.rhyme.com.au <http://www.rhyme.com.au/&gt;
| / \|
| --________--
GPG key available upon request. | /
|/