public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Noah Misch <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Joe Conway <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: Guo, Adam <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Jim Mlodgenski <[email protected]>
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Date: Fri, 06 Sep 2024 18:36:53 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAD21AoDJEKZO_=szRtOTX6we6wC_wWsHXH1zcEqza2vHE-YW4Q@mail.gmail.com>
<[email protected]>
<CAD21AoBO-iL=UgHKQrKE=7zBrMYR_fAhLb8AGo_kmNgmkPKuQA@mail.gmail.com>
<[email protected]>
<CAD21AoC=7oF29N6iKaTssn-rRGnoTVSLzTQh4ia4ZUO1iKKc_w@mail.gmail.com>
<[email protected]>
Noah Misch <[email protected]> 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
view thread (21+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox