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

Noah Misch <noah(at)leadboat(dot)com> writes:
> Yes, that's one way to make it work. If we do it that way, it would be
> critical to make the ALTER EXTENSION UPDATE run before anything uses the
> index. Otherwise, we'll run new v18 "signed char" code on a v17 "unsigned
> char" data file. Running ALTER EXTENSION UPDATE early enough should be
> feasible, so that's fine. Some other options:

> - If v18 "pg_dump -b" decides to emit CREATE INDEX ... gin_trgm_ops_unsigned,
> then make it also emit the statements to create the opclass.

> - Ship pg_trgm--1.6--1.7.sql in back branches. If the upgrade wants to use
> gin_trgm_ops_unsigned, require the user to ALTER EXTENSION UPDATE first.
> (In back branches, the C code behind gin_trgm_ops_unsigned could just raise
> an error if called.)

I feel like all of these are leaning heavily on users to get it right,
and therefore have a significant chance of breaking use-cases that
were perfectly fine before.

Remind me of why we can't do something like this:

* Add APIs that allow opclasses to read/write some space in the GIN
metapage. (We could get ambitious and add such APIs for other AMs
too, but doing it just for GIN is probably a prudent start.) Ensure
that this space is initially zeroed.

* In gin_trgm_ops, read a byte of this space and interpret it as
0 = unset
1 = signed chars
2 = unsigned chars
If the value is zero, set the byte on the basis of the native
char-signedness of the current platform. (Obviously, a
secondary server couldn't write the byte, and would have to
wait for the primary to update the value. In the meantime,
it's no more broken than today.)

* Subsequently, use either signed or unsigned comparisons
based on that value.

This would automatically do the right thing in all cases that
work today, and it'd provide the ability for cross-platform
replication to work in future. You can envision cases where
transferring a pre-existing index to a platform of the other
stripe would misbehave, but they're the same cases that fail
today, and the fix remains the same: reindex.

regards, tom lane