On Tue, Apr 23, 2024 at 11:57 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > "Guo, Adam" <adam...@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.
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
fix_signedness_issue_in_pg_trgm.patch
Description: Binary data
