Should we call it quits on support for 32-bit

[Paul Ramsey]

There’s a theory and practice thing going on here. All the effort going into maintaining 32-bit CI is kind of wasted if none of the issues ever gets fixed. And the lack of easy access to workable 32-dev dev envs makes it unlikely they will get any attention. Also, the last of 32-bit users strongly depresses the sense of any particular urgency to addressing the issues. They *might* be symptoms of some other larger problem. Or they might be quirks of the 32-bit platform. So, priority ends up low.

ATB,

P

> On Aug 19, 2024, at 4:41 PM, Regina Obe <lr at pcorp.us> wrote:
> 
>> I just kicked off a build of postgresql 16 on a NetBSD 10 RPI3 with 1G of
> RAM,
>> running as earmv7hf-el.  I'll see how that goes and then build postgis
> (sticking
>> to releases first).
> 
> Thanks Greg let us know how this goes.
> Yah part of me feels that these are real issues because of invalid types and
> so we gain something 
> from still testing on these architectures and trying to fix them in due
> time.
> 
> But the other part of me just wants those 32-bits off our CI trac radar.  So
> my first thought is just remove
> them, maybe check in to make sure they still compile or reduce the tests
> down to just "It compiles" we are done.
> 
> https://trac.osgeo.org/postgis  (the FreeBSD 12 x86 32-bit, which I know I
> got to upgrade still seems to be doing okay).
> 
> So that way, we can say, we do not guarantee all tests will pass on 32-bit
> architectures.
> 
> To be fair to berrie, berrie (our Rasberry pi arm 32-bit running Debian 11 )
> does just fine on the regular tests.
> It's our garden crasher of tests designed to crash servers with invalid
> inputs that she's crashing on and I think at the moment only our Rasberries
> are doing those crasher tests and Arm 64 is doing just fine on that suite of
> tests.
> 
> The gitlab one is more troubling just returning wrong answers and nothing I
> can replicate on any of the other 32-bit cis we have.
> 
> 
>