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

-----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-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Re: To 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.

A new example for this has just arrived, in pgpool2 4.5.3:

https://pgdgbuild.dus.dg-i.net/job/pgpool2-binaries/architecture=i386,distribution=sid/130/console

10:39:04 snprintf.c:409:1: error: conflicting types for ‘strchrnul’; have ‘const char *(const char *, int)’
10:39:04 409 | strchrnul(const char *s, int c)
10:39:04 | ^~~~~~~~~
10:39:04 In file included from snprintf.c:43:
10:39:04 /usr/include/string.h:286:14: note: previous declaration of ‘strchrnul’ with type ‘char *(const char *, int)’
10:39:04 286 | extern char *strchrnul (const char *__s, int __c)
10:39:04 | ^~~~~~~~~

64-bit builds are fine.

So we'll definitely proceed with removing 32-bit extensions.

Christoph

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 8/21/24 18:32, Christoph Berg wrote:

10:39:04 snprintf.c:409:1: error: conflicting types for ‘strchrnul’; have ‘const char *(const char *, int)’
10:39:04 409 | strchrnul(const char *s, int c)
10:39:04 | ^~~~~~~~~
10:39:04 In file included from snprintf.c:43:
10:39:04 /usr/include/string.h:286:14: note: previous declaration of ‘strchrnul’ with type ‘char *(const char *, int)’
10:39:04 286 | extern char *strchrnul (const char *__s, int __c)
10:39:04 | ^~~~~~~~~

Erm, that's a different class of bug: for some reason, strchrnul() is
defined as returning a pointer to a non-const char, but this pointer is
derived from the pointer to const char passed in.

The extension for some reason provides its own variant (probably a bug
in a configure script) instead of using the glibc version.

That is not a 32 bit bug, but an indication of something else being broken.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Re: Simon Richter

That is not a 32 bit bug, but an indication of something else being broken.

It is the same problem in the sense that 64-bit architectures are
fine, and something (probably in some autoconf script) is broken on
32-bit. The point here is that these are always weird bugs in weird
places that upstream doesn't see because they aren't on 32-bit, and
wasting maintainer time here doesn't pay off because there are no
users on 32-bit.

It's likely just a 1-line fix, but finding that one line would take at
least 30min.

Christoph

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)