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

From Jakub Wartak
Subject Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h")
Date
Msg-id CAKZiRmzdSQ8TBmGX_Dyo9zVpctoGc6MUdYiiO8jsu-BVx==60Q@mail.gmail.com
Whole thread
In response to Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h")  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h")
Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h")
List 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.



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Enhancing Memory Context Statistics Reporting
Next
From: Nathan Bossart
Date:
Subject: Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h")