From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
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-02 21:08:42 |
Message-ID: | 1196610.1759439322@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Thu, Oct 02, 2025 at 10:29:39PM +0200, Tomas Vondra wrote:
>> I don't follow the reasoning. If there are no aarch64 platforms running
>> in big-endian mode (at least not supported ones), then how would you
>> even build Postgres in such environment?
>>
>> Also, what's the benefit of disabling it? Is it about disabling
>> something we can't meaningfully test (even though we still support other
>> big-endian platforms, right?). Or does it affect the SIMD stuff somehow?
> 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?
Given that we don't believe any OS support exists for this
combination, I'm not sure why we should expend configure cycles
on rejecting it. If anyone ever builds such a platform and tries
to run Postgres on it, either it will work or they'll have to start
writing patches. But that applies to a whole lot of not-actively-
tested configurations. I don't see why we should go out of our
way to reject this one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2025-10-02 21:15:15 | Re: [PATCH] Add tests for Bitmapset |
Previous Message | Tom Lane | 2025-10-02 21:02:44 | Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs |