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

On 03.05.24 16:13, Tom Lane wrote:
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
>> On 30.04.24 19:29, Tom Lane wrote:
>>> 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.
>
>> But note that option 1 would prevent some replication that is currently
>> working.
>
> The point of this thread though is that it's working only for small
> values of "work". People are rightfully unhappy if it seems to work
> and then later they get bitten by compatibility problems.
>
> Treating char signedness as a machine property in pg_control would
> signal that we don't intend to make it work, and would ensure that
> even the most minimal testing would find out that it doesn't work.
>
> If we do not do that, it seems to me we have to buy into making
> it work. That would mean dealing with the consequences of an
> incompatible change in pg_trgm indexes, and then going through
> the same dance again the next time(s) similar problems are found.

Yes, that is understood. But anecdotally, replicating between x86-64
arm64 is occasionally used for upgrades or migrations. In practice,
this appears to have mostly worked. If we now discover that it won't
work with certain index extension modules, it's usable for most users.
Even if we say, you have to reindex everything afterwards, it's probably
still useful for these scenarios.

The way I understand the original report, the issue has to do
specifically with how signed and unsigned chars compare differently. I
don't imagine this is used anywhere in the table/heap code. So it's
plausible that this issue is really contained to indexes.

On the other hand, if we put in a check against this, then at least we
can answer any user questions about this with more certainty: No, won't
work, here is why.