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

From Masahiko Sawada
Subject Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Date
Msg-id CAD21AoDWreYF=U1KL6z-WROLfDL7yajaw2XXCcv3MME=Z5o5pQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Oct 1, 2024 at 8:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Noah Misch <noah@leadboat.com> writes:
> > On Tue, Oct 01, 2024 at 11:55:48AM -0700, Masahiko Sawada wrote:
> >> Considering that the population of database cluster signedness will
> >> converge to signedness=true in the future, we can consider using
> >> -fsigned-char to prevent similar problems for the future. We need to
> >> think about possible side-effects as well, though.
>
> > It's good to think about -fsigned-char.  While I find it tempting, several
> > things would need to hold for us to benefit from it:
>
> > - Every supported compiler has to offer it or an equivalent.
> > - The non-compiler parts of every supported C implementation need to
> >   cooperate.  For example, CHAR_MIN must change in response to the flag.  See
> >   the first comment in cash_in().
> > - Libraries we depend on can't do anything incompatible with it.
>
> > Given that, I would lean toward not using -fsigned-char.  It's unlikely all
> > three things will hold.  Even if they do, the benefit is not large.
>
> I am very, very strongly against deciding that Postgres will only
> support one setting of char signedness.  It's a step on the way to
> hardware monoculture, and we know where that eventually leads.
> (In other words, I categorically reject Sawada-san's assertion
> that signed chars will become universal.  I'd reject the opposite
> assertion as well.)

Thank you for pointing this out. I agree with both of you.

Regards,

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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: bgwrite process is too lazy
Next
From: Heikki Linnakangas
Date:
Subject: Re: Rename PageData to XLogPageData