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