Re: Replication between 64/32bit systems?

From: Hannes Erven <hannes(at)erven(dot)at>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Replication between 64/32bit systems?
Date: 2011-09-22 20:35:46
Message-ID: 4E7B9C22.7020904@erven.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Greg Smith 2011-09-22 20:43:54 Re: Materialized views in Oracle
Previous Message e-blokos 2011-09-22 19:34:26 about synchronous_standby_names or sync replic