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

On Tue, Apr 23, 2024 at 5: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 this, should we try to do better with binary compatibility
checks using ControlFileData? AFAICS they are supposed to check if
the database cluster is binary compatible with the running
architecture. But it obviously allows incompatibilities.

------
Regards,
Alexander Korotkov