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 1696557.1714498172@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation  (Alexander Korotkov <aekorotkov@gmail.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  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
Alexander Korotkov <aekorotkov@gmail.com> writes:
> I agree that storing char signedness might seem weird.  But it appears
> that we already store indexes that depend on char signedness.  So,
> it's effectively property of bits-on-disk even though it affects
> indirectly.  Then I see two options to make the picture consistent.
> 1) Assume that char signedness is somehow a property of bits-on-disk
> even though it's weird.  Then pg_trgm indexes are correct, but we need
> to store char signedness in pg_control.
> 2) Assume that char signedness is not a property of bits-on-disk.
> Then pg_trgm indexes are buggy and need to be fixed.
> What do you think?

The problem with option (2) is the assumption that pg_trgm's behavior
is the only bug of this kind, either now or in the future.  I think
that's just about an impossible standard to meet, because there's no
realistic way to test whether char signedness is affecting things.
(Sure, you can compare results across platforms, but maybe you
just didn't test the right case.)

Also, the bigger picture here is the seeming assumption that "if
we change pg_trgm then it will be safe to replicate from x86 to
arm".  I don't believe that that's a good idea and I'm unwilling
to promise that it will work, regardless of what we do about
char signedness.  That being the case, I don't want to invest a
lot of effort in the signedness issue.  Option (1) is clearly
a small change with little if any risk of future breakage.
Option (2) ... not so much.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: TerminateOtherDBBackends code comments inconsistency.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: A problem about partitionwise join