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 →
  1. Remove support for 8 byte tear free read/write on 32-bit