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

Jakub Wartak <jakub.wartak@enterprisedb.com>

From: Jakub Wartak <jakub.wartak@enterprisedb.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Andres Freund <andres@anarazel.de>, Tomas Vondra <tv@fuzzy.cz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2026-03-12T13:54:58Z
Lists: pgsql-hackers
On Thu, Mar 12, 2026 at 2:33 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 12 Mar 2026, at 08:57, Jakub Wartak <jakub.wartak@enterprisedb.com> wrote:
>
> > ..I think that the topic of removal 32-bit support deserves better transparency,
> > so I'm sending this under new subject.
>
>
> My interpretation of the comments in the thread was to remove 32-bit support
> for 8 byte single-copy atomicity, not 32-bit support entirely.  Maybe that was
> a misunderstanding but it seems like a better place to start given that it
> apparently doesn't work with no one complaining about it.
>

Right, you might be spot-on: I might have overreacted to this. But probably
the main question is still valid (and now we have thread! :)). Should we
maintain builds/testing for 32-bit PostgreSQL in 2026 and beyond?

(Everyone else in IT world is getting rid of support for even 686).

I remember researching if there any real 32-bit users out there and come up
with nothing (maybe I'm wrong on this), but maybe that's the right moment to at
least start deprecating 32-bits?

-J.



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove support for 8 byte tear free read/write on 32-bit