Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h")

On Wed, Mar 11, 2026 at 6:50 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Wed, Mar 11, 2026 at 11:51:23AM -0400, Andres Freund wrote:
> > I do think we should drop the 32bit support, rather than fixing the typos.
>
> +1
>
> > I also just can't get excited about expending any work on performance for
> > 32bit builds.
>
> +1. I'd go so far as to say that we should start removing all
> 32-bit-specific inline assembly, intrinsics, etc. from the tree. I doubt
> they're worth the complexity and maintenance costs.

Hi all,

I've marked this patch (to fix typos) as returned with feedback in CF. I'm +1
(mainly due to eliminating complexity and saving time for
'Linux - Debian Trixie - Meson' in Cirrus CI as it will be faster without
testing the 32-bit stuff there; last run was like ~+7 mins for 'test_world_32'
alone, and that's almost like 50% of the whole time there), but I think that
the topic of removal 32-bit support deserves better transparency, so I'm
sending this under new subject.

I propose simply for now that that if there's consensus to drop the 32-bits
support, then in the release notes of PG19 we could simply add some
deprecation notice/warning like "PostgreSQL 19 is _probably_ the last release
to provide support for 32-bits architectures. Please consider planning upgrade
to 64-bit architecture." (and this costs us nothing, and gives any potential
user additional year, and project would have even freedom to continue for
couple releases still with 32-bits until somebody develops proper patch).

The only trouble I see is that we should probalby excplictly continue to
provide 32-bit client support (to allow embedded clients/IOT to continue).

-J.