Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation - Mailing list pgsql-hackers

On Mon, Sep 16, 2024 at 9:24 AM Noah Misch <noah@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 <noah@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.

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.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com