From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Guo, Adam" <adamguo@amazon.com>
cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
In-reply-to: <CB11ADBC-0C3F-4FE0-A678-666EE80CBB07@amazon.com>
References: <CB11ADBC-0C3F-4FE0-A678-666EE80CBB07@amazon.com>
Comments: In-reply-to "Guo, Adam" <adamguo@amazon.com>
	message dated "Tue, 23 Apr 2024 14:45:20 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3335674.1713884256.1@sss.pgh.pa.us>
Date: Tue, 23 Apr 2024 10:57:36 -0400
Message-ID: <3335675.1713884256@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3335675.1713884256%40sss.pgh.pa.us>
Precedence: bulk

"Guo, Adam" <adamguo@amazon.com> writes:
> I would like to report an issue with the pg_trgm extension on
> cross-architecture replication scenarios. When an x86_64 standby
> server is replicating from an aarch64 primary server or vice versa,
> the gist_trgm_ops opclass returns different results on the primary
> and standby.

I do not think that is a supported scenario.  Hash functions and
suchlike are not guaranteed to produce the same results on different
CPU architectures.  As a quick example, I get

regression=# select hashfloat8(34);
 hashfloat8 
------------
   21570837
(1 row)

on x86_64 but

postgres=# select hashfloat8(34);
 hashfloat8 
------------
 -602898821
(1 row)

on ppc32 thanks to the endianness difference.

> Given that this has problem has come up before and seems likely to
> come up again, I'm curious what other broad solutions there might be
> to resolve it?

Reject as not a bug.  Discourage people from thinking that physical
replication will work across architectures.

			regards, tom lane