Date: Thu, 15 Aug 2024 15:16:37 +0200
From: Christoph Berg <myon@debian.org>
To: debian-devel <debian-devel@lists.debian.org>
Cc: PostgreSQL in Debian <pgsql-pkg-debian@lists.postgresql.org>
Subject: The end of 32-bit PostgreSQL support in Debian
Message-ID: <Zr3_tXWr0VQol-VH@msg.df7cb.de>
Mail-Followup-To: Christoph Berg <myon@debian.org>,
	debian-devel <debian-devel@lists.debian.org>,
	PostgreSQL in Debian <pgsql-pkg-debian@lists.postgresql.org>
References: 
 <CAOMoQbQak2uyt5oGUaTWHPn3nWo+Q97JWGMWM-bqq6yFWFw+gw@mail.gmail.com>
 <ZqZ1agsCfHd9eRU0@msg.df7cb.de>
 <CABUevEz8tX53wT-1pLXGVSndavCxKBCy47i-5_jpNKtsy7T5cA@mail.gmail.com>
 <4e3e01a0-bc53-45cf-8f53-54781ae28cf4@pgmasters.net>
 <ZqemNrqsjIfuIk9Z@msg.df7cb.de>
 <9BDDFA98-9637-4BC4-BBF6-45CF03DBCD9D@debian.org>
 <EFA87281-1B05-45D0-A814-9C871503542D@thebuild.com>
 <CAOMoQbTdRq4t2hxxi2xMLHE8W-xR2d-XL2AK3WqzH5Eb9YODVg@mail.gmail.com>
 <Zqj_4nlZEqfbQ2aM@msg.df7cb.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="e+rVGVLlTGQBZ9Xi"
Content-Disposition: inline
In-Reply-To: <Zqj_4nlZEqfbQ2aM@msg.df7cb.de>
Archived-At: 
 <https://www.postgresql.org/message-id/Zr3_tXWr0VQol-VH%40msg.df7cb.de>
Precedence: bulk


--e+rVGVLlTGQBZ9Xi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi debian-devel,

it has probably been a decade since I've last seen a PostgreSQL
installation in the wild on a 32-bit machine. PostgreSQL itself works
fine there, but more and more extensions are not compatible anymore,
either deliberately, or (more common) because of subtle bugs in printf
patterns, double precision values not fitting in a PG Datum, or other
porting problems. Each time this happens, someone has to go digging
what's wrong this time, while in reality, there are likely no users at
all for this PG extension on 32-bit architectures.

Hence, we would like to stop building PG extensions on 32-bit
architectures. The server packages will still build, but extension
packages will be restricted to 64-bit architectures. (If the server
starts to break as well, we could strip down the PG packages to
provide libpq5.deb and friends only.)

I haven't yet decided whether to extend that to PG applications, but
this would likely be the preferred fix for anything 32-bit related in
case of problems.

apt.postgresql.org has already stopped building 32-bit packages for
all releases past past buster, and in the years since then, I've only
received a single question about that. (Which wasn't a user but the
pgbackrest upstream trying to test their software against 32-bit, so
with the same problem.)

On pgsql-pkg-debian I proposed this plan:

* Remove buster-pgdg from apt.pg.o (buster-lts was EOLed last month)

* Remove i386 from sid-pgdg (packages are still preserved on
  apt-archive.postgresql.org)

* Upload postgresql-17 to Debian unstable, with all architectures
  supported [*] (once rc1 is there)

* When re-uploading all extensions to Debian to transition them from
  16 to 17, disable extensions on 32-bit archs. Adding this should do
  the trick:

  Build-Depends: architecture-is-64-bit <!pkg.postgresql.32-bit>,

  That way, people could still build extension packages manually if
  they really wanted (dpkg-buildpackage -Ppkg.postgresql.32-bit).

* Remove postgresql-16 from unstable

Comments?

Christoph

[*] On a side note, 32-bit powerpc did actually start to break:
https://buildd.debian.org/status/logs.php?pkg=postgresql-17&ver=17%7Ebeta2-1&arch=powerpc
I told the package to ignore the regression test results there with
the next postgresql-common upload:
https://salsa.debian.org/postgresql/postgresql-common/-/commit/593fa32fa0c6d2a963a7b3b514d1d6a2423ef534

--e+rVGVLlTGQBZ9Xi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAma9/7IACgkQTFprqxLS
p67Pug//SLUzd6PU3Pq3T9XXcP47EV/FSLZ0qZ/iUKwtW/5YAQXtdL2xMmoiN1+f
G9P6nyMdHtVPBp4GhEj//juPkMLN8ZUBCesbNDk+43XM9xv8PBBlTLT3ph5pwp32
XDQ9OYrWqgY7+bGdxcKMNKkctHUHMkshe8YZMalAjKnlpkTD9vUXJD2DKmbSNB83
MjTljVRsGBMC21vPOP4BhwJNdaAfAl83+cwwruKu+AJbYQwLkz8QvIdaOOXgzRMm
W0Ghh8rRhAIdjZkkbJN4oZzaAlK9z0lBeOGfyYYzNRI3TnH3NRb8yCmjbdwXbP0I
Yi+6AfwkxihPF6thw92REC4fMnPzejCFYpjvqh1UtPlHzjs4XWaV0P3yztOUS32M
QY6gp43EVy1U2+DI/DDDul4wl2x+3n3M6A2vJ4J0D9TfEZCWBfSpbrKB4FK93WnW
0UEZlml5jAsvwNtOCNDOM68c05jHO5gLrKZ65mNFOrbpkfBBnw8p3YWp+yClPuj5
2HFTJiba28li5Ea/SiWfb/cLtMynwUYzfj7hDkow8Wwa+lg/P9hb7khP17q6fVex
I0ttq7qg2zSOLTf0dJIbi07I1D6oz+joPyXPhvFhBZk61I/8V4Js+Sp6ZAXlibNs
S/FKLH+0sK02zhNEVTbjjaPd2GHEA2c950WqiGiSMBFbwKwEtJE=
=KpFQ
-----END PGP SIGNATURE-----

--e+rVGVLlTGQBZ9Xi--