Re: The end of 32-bit PostgreSQL support?

On 7/29/24 16:39, Magnus Hagander wrote:
> On Sun, Jul 28, 2024 at 6:44 PM Christoph Berg <myon(at)debian(dot)org
> <mailto:myon(at)debian(dot)org>> wrote:
>
> Re: Bradford Boyle
> > pgvector has released 0.7.3 and I have update the packaging on
> Salsa [1] to
> > update the Debian package. I'd like to request a review and
> upload, as
> > cycles permit.
>
> Hi Bradford,
>
> thanks, uploaded!
>
> > There was a build failure for sid/i386 in Salsa's CI pipeline. I
> suspect
> > this was caused by the new addition of gcc-14 to sid since the
> > problematic code was unchanged between 0.7.2 and 0.7.3. Reviewing the
> > console output from Salsa's pipeline for 0.7.2 [2], shows that gcc-13
> > was used for building 0.7.2. I was able to resolve the build
> failure by
> > conditionally adding -msse2 to PG_CFLAGS when DEB_HOST_ARCH is i386.
>
> Having seen how much time you had to spend on resolving this, I wonder
> it it is finally time to sunset the support for 32-bit architectures
> in PostgreSQL on Debian. I can't even remember when I've seen a 32-bit
> cluster in the wild, and there's been zero complaints when I disabled
> i386 support on apt.postgresql.org <http://apt.postgresql.org> for
> bullseye. There is a steady
> stream of extension bugs specific to 32-bit, upstreams have little way
> and incentive to fix that, and we waste a lot of time for probably no
> users.
>
> Comments? Disable it all (but keep libpq5 for applications)? Continue
> to build the server since it works, but disable building all
> extensions?
>
> Isn't Raspberry Pi still used pretty frequently in 32-bit? Not that they
> are great big PostgreSQL users, but it's not nothing.  They do their own
> downstream I believe, but if upstream dropped postgres I'm sure so would
> they.

Pi OS has had a 64-bit version for two years now, so I think that would
be the way to go for anyone needing compatibility.

> That said they're also a lot less likely to use the advanced extensions
> I would guess, so maybe a middle ground could be to provide the base
> postgresql packages only?

This was one of the options Christoph proposed so I'm certainly OK with it.

Regards,
-David