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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: "Guo, Adam" <adamguo(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Date: 2024-04-30 17:29:32
Message-ID: 1696557.1714498172@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> I agree that storing char signedness might seem weird. But it appears
> that we already store indexes that depend on char signedness. So,
> it's effectively property of bits-on-disk even though it affects
> indirectly. Then I see two options to make the picture consistent.
> 1) Assume that char signedness is somehow a property of bits-on-disk
> even though it's weird. Then pg_trgm indexes are correct, but we need
> to store char signedness in pg_control.
> 2) Assume that char signedness is not a property of bits-on-disk.
> Then pg_trgm indexes are buggy and need to be fixed.
> What do you think?

The problem with option (2) is the assumption that pg_trgm's behavior
is the only bug of this kind, either now or in the future. I think
that's just about an impossible standard to meet, because there's no
realistic way to test whether char signedness is affecting things.
(Sure, you can compare results across platforms, but maybe you
just didn't test the right case.)

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.
Option (2) ... not so much.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-04-30 17:31:09 Re: A problem about partitionwise join
Previous Message Noah Misch 2024-04-30 17:06:18 Re: TerminateOtherDBBackends code comments inconsistency.