MIME-Version: 1.0
References: 
 <CAOMoQbQak2uyt5oGUaTWHPn3nWo+Q97JWGMWM-bqq6yFWFw+gw@mail.gmail.com>
 <ZqZ1agsCfHd9eRU0@msg.df7cb.de>
In-Reply-To: <ZqZ1agsCfHd9eRU0@msg.df7cb.de>
From: Magnus Hagander <magnus@hagander.net>
Date: Mon, 29 Jul 2024 11:39:55 +0200
Message-ID: 
 <CABUevEz8tX53wT-1pLXGVSndavCxKBCy47i-5_jpNKtsy7T5cA@mail.gmail.com>
Subject: Re: The end of 32-bit PostgreSQL support?
To: Christoph Berg <myon@debian.org>
Cc: Bradford Boyle <bradford.d.boyle@gmail.com>,
 pgsql-pkg-debian@lists.postgresql.org,
	andrew@ankane.org
Content-Type: multipart/alternative; boundary="000000000000807657061e5fa5ea"
Archived-At: 
 <https://www.postgresql.org/message-id/CABUevEz8tX53wT-1pLXGVSndavCxKBCy47i-5_jpNKtsy7T5cA%40mail.gmail.com>
Precedence: bulk

--000000000000807657061e5fa5ea
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 28, 2024 at 6:44=E2=80=AFPM Christoph Berg <myon@debian.org> wr=
ote:

> Re: Bradford Boyle
> > pgvector has released 0.7.3 and I have update the packaging on Salsa [1=
]
> to
> > update the Debian package. I'd like to request a review and upload, as
> > cycles permit.
>
> Hi Bradford,
>
> thanks, uploaded!
>
> > There was a build failure for sid/i386 in Salsa's CI pipeline. I suspec=
t
> > this was caused by the new addition of gcc-14 to sid since the
> > problematic code was unchanged between 0.7.2 and 0.7.3. Reviewing the
> > console output from Salsa's pipeline for 0.7.2 [2], shows that gcc-13
> > was used for building 0.7.2. I was able to resolve the build failure by
> > conditionally adding -msse2 to PG_CFLAGS when DEB_HOST_ARCH is i386.
>
> Having seen how much time you had to spend on resolving this, I wonder
> it it is finally time to sunset the support for 32-bit architectures
> in PostgreSQL on Debian. I can't even remember when I've seen a 32-bit
> cluster in the wild, and there's been zero complaints when I disabled
> i386 support on apt.postgresql.org for bullseye. There is a steady
> stream of extension bugs specific to 32-bit, upstreams have little way
> and incentive to fix that, and we waste a lot of time for probably no
> users.
>
> Comments? Disable it all (but keep libpq5 for applications)? Continue
> to build the server since it works, but disable building all
> extensions?
>
>
Isn't Raspberry Pi still used pretty frequently in 32-bit? Not that they
are great big PostgreSQL users, but it's not nothing.  They do their own
downstream I believe, but if upstream dropped postgres I'm sure so would
they.

That said they're also a lot less likely to use the advanced extensions I
would guess, so maybe a middle ground could be to provide the base
postgresql packages only?

//Magnus

--000000000000807657061e5fa5ea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Jul 28, 2024 at 6:44=E2=80=AFPM C=
hristoph Berg &lt;<a href=3D"mailto:myon@debian.org">myon@debian.org</a>&gt=
; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">Re: Bradford Boyle<br>
&gt; pgvector has released 0.7.3 and I have update the packaging on Salsa [=
1] to<br>
&gt; update the Debian package. I&#39;d like to request a review and upload=
, as<br>
&gt; cycles permit.<br>
<br>
Hi Bradford,<br>
<br>
thanks, uploaded!<br>
<br>
&gt; There was a build failure for sid/i386 in Salsa&#39;s CI pipeline. I s=
uspect<br>
&gt; this was caused by the new addition of gcc-14 to sid since the<br>
&gt; problematic code was unchanged between 0.7.2 and 0.7.3. Reviewing the<=
br>
&gt; console output from Salsa&#39;s pipeline for 0.7.2 [2], shows that gcc=
-13<br>
&gt; was used for building 0.7.2. I was able to resolve the build failure b=
y<br>
&gt; conditionally adding -msse2 to PG_CFLAGS when DEB_HOST_ARCH is i386.<b=
r>
<br>
Having seen how much time you had to spend on resolving this, I wonder<br>
it it is finally time to sunset the support for 32-bit architectures<br>
in PostgreSQL on Debian. I can&#39;t even remember when I&#39;ve seen a 32-=
bit<br>
cluster in the wild, and there&#39;s been zero complaints when I disabled<b=
r>
i386 support on <a href=3D"http://apt.postgresql.org" rel=3D"noreferrer" ta=
rget=3D"_blank">apt.postgresql.org</a> for bullseye. There is a steady<br>
stream of extension bugs specific to 32-bit, upstreams have little way<br>
and incentive to fix that, and we waste a lot of time for probably no<br>
users.<br>
<br>
Comments? Disable it all (but keep libpq5 for applications)? Continue<br>
to build the server since it works, but disable building all<br>
extensions?<br><br></blockquote><div><br></div><div>Isn&#39;t Raspberry Pi =
still used pretty frequently in 32-bit? Not that they are great big Postgre=
SQL users, but it&#39;s not nothing.=C2=A0 They do their own downstream I b=
elieve, but if upstream dropped postgres I&#39;m sure so would they.</div><=
div><br></div><div>That said they&#39;re also a lot less likely to use the =
advanced extensions I would guess, so maybe a middle ground could be to pro=
vide the base postgresql packages only?</div><div><br></div><div>//Magnus</=
div><div><br></div></div><div dir=3D"ltr" class=3D"gmail_signature"><div di=
r=3D"ltr"></div></div></div>

--000000000000807657061e5fa5ea--