Re: Physical replication from x86_64 to ARM64 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Physical replication from x86_64 to ARM64
Date
Msg-id E8D08ECE-EEC0-43F1-9533-C46547580454@anarazel.de
Whole thread Raw
In response to Re: Physical replication from x86_64 to ARM64  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Physical replication from x86_64 to ARM64  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
Hi,


On September 14, 2021 7:11:25 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Aleksander Alekseev <aleksander@timescale.com> writes:
>>> Initial experiments show no observable problems when copying PGDATA or in
>>> fact using physical streaming replication between the two CPU architectures.
>
>> That's an interesting result. The topic of physical replication
>> compatibility interested me much back in 2017 and I raised this question on
>> PGCon [1]. As I recall the compatibility is not guaranteed, nor tested, and
>> not going to be, because the community doesn't have resources for this.
>
>Yeah.  As far as the hardware goes, if you have the same endianness,
>struct alignment rules, and floating-point format [1], then physical
>replication ought to work.  Where things get far stickier is if the
>operating systems aren't identical, because then you have very great
>risk of text sorting rules not being the same, leading to index
>corruption [2].  In modern practice that tends to be a bigger issue
>than the hardware, and we don't have any goo d way to check for it.

I'd also be worried about subtle changes in floating point math results, and that subsequently leading to index
mismatches.Be that because the hardware gives differing results, or because libc differences. 

Regards,

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: [BUG] Unexpected action when publishing partition tables
Next
From: Sergei Kornilov
Date:
Subject: Re: refactoring basebackup.c