Re: Replication between 64/32bit systems? - Mailing list pgsql-general

From Hannes Erven
Subject Re: Replication between 64/32bit systems?
Date
Msg-id 4E7B9C22.7020904@erven.at
Whole thread Raw
In response to Re: Replication between 64/32bit systems?  (Chris Ernst <cernst@zvelo.com>)
Responses Re: Replication between 64/32bit systems?  (John R Pierce <pierce@hogranch.com>)
Re: Replication between 64/32bit systems?  (Craig Ringer <ringerc@ringerc.id.au>)
Re: Replication between 64/32bit systems?  (Hannes Erven <hannes@erven.at>)
List pgsql-general
Folks,


>> Sure enough, what I'd really like to do is replicate from a Windows
>> (or Linux) 64bit master to a Linux 32bit slave -- that's what I
>> currently have easily available.


thank you for your replies -- unfortunately, I'm not very content with
"it simply won't work" without understanding what the reasons are. ;-)

Endianness, OK, but that's the same on i32/64 platforms. So is it just
the length of the int & friends data types? I don't (yet) believe
there's no way around that.


So I tried compiling the postgres sources (identical version as on
server) with the following gcc options in CFLAGS:
    -m128bit-long-double
    -malign-double

This leads me to a pg_controldata executable that does no more complain
about invalid CRCs and it also prints out valid-looking data.
But, the postmaster process does not start up -- no error, but it just
doesn't come up.

When starting with --single, I get the following output:

LOG:  database system was shut down at 2011-09-22 17:29:34 CEST
DEBUG:  primary_conninfo = 'host=192.168.xx.yy port=5432 user=yyy
password=zzz'
DEBUG:  standby_mode = 'on'
LOG:  entering standby mode
DEBUG:  checkpoint record is at 3/EB000378
DEBUG:  redo record is at 3/EB000378; shutdown TRUE
DEBUG:  next transaction ID: 0/14549; next OID: 483488
DEBUG:  next MultiXactId: 7; next MultiXactOffset: 13
DEBUG:  oldest unfrozen transaction ID: 654, in database 1
DEBUG:  transaction ID wrap limit is 2147484301, limited by database
with OID 1
LOG:  consistent recovery state reached at 3/EB0003D0
LOG:  record with zero length at 3/EB0003D0
DEBUG:  could not open file "pg_xlog/0000000100000003000000EB" (log file
3, segment 235): File or directory not found



So... it doesn't look to be that bad, is it?



I'm still hoping someone would give me a clue why 32/64 bit platform
xlogs are (and always will?) be absolutely incompatible... ???


Thanks again, and sorry for my "insisting"...

    -hannes

pgsql-general by date:

Previous
From: Christophe Pettus
Date:
Subject: Statistics collector failure messages on startup
Next
From: Greg Smith
Date:
Subject: Re: Materialized views in Oracle