On 03.05.24 16:13, Tom Lane wrote:
Peter Eisentraut <pe...@eisentraut.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.
