On Wed, Mar 11, 2026 at 6:50 PM Nathan Bossart <[email protected]> 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.
