From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, pgsql-hackers(at)postgresql(dot)org, andres(at)anarazel(dot)de |
Subject: | Re: disallow big-endian on aarch64 |
Date: | 2025-10-03 06:37:02 |
Message-ID: | 21b645b0-af32-4f73-b9f5-163075ed95bb@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02.10.25 23:31, Nathan Bossart wrote:
> On Thu, Oct 02, 2025 at 05:08:42PM -0400, Tom Lane wrote:
>> Nathan Bossart<nathandbossart(at)gmail(dot)com> writes:
>>> The benefit is that we can safely assume little-endian in AAarch64-specific
>>> code, and on the off-chance that someone tries to build Postgres in an
>>> AArch64/big-endian environment, we aren't pretending to support it.
>> Is that actually a meaningful benefit, ie can we remove any code
>> anywhere?
> I'm not aware of existing code that is broken, but some of the stuff I'm
> intending to commit soon to optimize hex_{encode,decode} might be sensitive
> to endianness. In any case, I don't think it's outside the realm of
> possibilities for architecture-specific code.
As a future direction, in cases like this I think it would be better to
write a static assertion. Then the check is self-contained in the C
code, perhaps next to the code it's trying to protect, perhaps with a
comment, and doesn't have to be maintained in some far-away configure
shell script.
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2025-10-03 06:52:05 | Re: Report bytes and transactions actually sent downtream |
Previous Message | Alexander Korotkov | 2025-10-03 06:31:33 | Re: VM corruption on standby |