| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Tomas Vondra <tv(at)fuzzy(dot)cz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| Subject: | Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h") |
| Date: | 2026-03-12 15:28:51 |
| Message-ID: | 4469.1773329331@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-03-12 15:30:25 | Re: Drop 32-bit support (was "Re: Fix typo 586/686 in atomics/arch-x86.h") |
| Previous Message | Fujii Masao | 2026-03-12 15:27:32 | Re: pg_stat_replication.*_lag sometimes shows NULL during active replication |