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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Дата
Msg-id 3335675.1713884256@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_trgm comparison bug on cross-architecture replication due to different char implementation  ("Guo, Adam" <adamguo@amazon.com>)
Ответы Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation  (Alexander Korotkov <aekorotkov@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Guo, Adam"
Дата:
Сообщение: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs