Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h")
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jakub Wartak <jakub.wartak@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Andres Freund <andres@anarazel.de>,
Daniel Gustafsson <daniel@yesql.se>, 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-12T15:28:51Z
Lists: pgsql-hackers
Jakub Wartak <jakub.wartak@enterprisedb.com> writes: > I propose simply for now that that if there's consensus to drop the 32-bits > support, I do not believe there is any such consensus, and I for one am against it. What was being discussed in the other thread was dropping some dedicated code paths for 32-bit arches, which is in line with the general policy that we've had for awhile of not optimizing for such builds anymore. But there's a long way from that to "it won't work at all". > 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). Yes, that's one of the good reasons for not dropping it altogether. *Maybe* there is an argument for not supporting 32-bit servers anymore, but I don't really buy that. Also, how are you going to test a 32-bit client build if the server has to be somewhere else? Building infrastructure to support that would quickly eat up whatever win is to be had. regards, tom lane
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