Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On Tue, Apr 23, 2024 at 11:57 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Guo, Adam" <adamguo(at)amazon(dot)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.

While cross-arch physical replication is not supported, I think having
architecture dependent differences is not good and It's legitimate to
fix it. FYI the 'char' data type comparison is done as though char is
unsigned. I've attached a small patch to fix it. What do you think?

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com