>
> 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
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 a
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
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 th
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
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
--
Sent via
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 syste
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-di
