Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Date
Msg-id 3335675.1713884256@sss.pgh.pa.us
Whole thread Raw
In response to pg_trgm comparison bug on cross-architecture replication due to different char implementation  ("Guo, Adam" <adamguo@amazon.com>)
Responses Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
List pgsql-hackers
"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



pgsql-hackers by date:

Previous
From: "Guo, Adam"
Date:
Subject: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Next
From: Robert Haas
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs