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 →
-
Remove support for 8 byte tear free read/write on 32-bit
- 801b9962e787 19 (unreleased) landed