Thread: PiTR and other architectures....
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) 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. Philip Warner
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.comPostgreSQL 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/> | / \| | --________-- GPG key available upon request. | / |/