On Tue, Sep 17, 2024 at 09:43:41PM -0700, Masahiko Sawada wrote: > On Mon, Sep 16, 2024 at 9:24 AM Noah Misch <n...@leadboat.com> wrote: > > On Thu, Sep 12, 2024 at 03:42:48PM -0700, Masahiko Sawada wrote: > > > On Tue, Sep 10, 2024 at 3:05 PM Noah Misch <n...@leadboat.com> wrote: > > > > On Tue, Sep 10, 2024 at 05:56:47PM -0400, Tom Lane wrote: > > > > > Got it. So now I'm wondering if we need all the complexity of storing > > > > > stuff in the GIN metapages. Could we simply read the (primary's) > > > > > signedness out of pg_control and use that? > > > > > I've attached a PoC patch for this idea. We write the default char > > > signedness to the control file at initdb time. Then when comparing two > > > trgms, pg_trgm opclasses use a comparison function based on the char > > > signedness of the cluster. I've confirmed that the patch fixes the > > > reported case at least. > > > > I agree that proves the concept. > > Thanks. I like the simplicity of this approach. If we agree with this > approach, I'd like to proceed with it.
Works for me. > Regardless of what approach we take, I wanted to provide some > regression tests for these changes, but I could not come up with a > reasonable idea. It would be great if we could do something like > 027_stream_regress.pl on cross-architecture replication. But just > executing 027_stream_regress.pl on cross-architecture replication > could not be sufficient since we would like to confirm query results > as well. If we could have a reasonable tool or way, it would also help > find other similar bugs related architectural differences. Perhaps add a regress.c function that changes the control file flag and flushes the change to disk?
