Hi Christoph Am 25.09.2025 um 17:42 schrieb Christoph Berg:
Thanks, that sounds like a solution I was looking for. Might be an idea to implement this into the maintainer scripts as well for armhf, to prevent users from being stuck with PostgreSQL 17 but v15 clusters? I mean sure, one should have a backup etc. We will implement and test pg_dumpall + restore for our users. If this works, I could open a PR to patch v15 and v17 maintainer scripts accordingly.The maintainer scripts have learned about automatic upgrades for the easy cases only now, it was always manual before. I don't think retroactively patching for that extra case now is sensible - it also needs a lot of disk space, which is probably not available (and even if it was, it might not be in the location where the dump would be put by default). The next trixie->forky upgrade should work normal again (and will have automatic upgrades).
The upgrade is still a manual task, I am not aware that the maintainer scripts did anything about it? Only the APT config prevents old postgresql-* removal in all but Bookworm => Trixie armhf cases.
But I agree such is not trivially implemented, I have not thought it through. As an alternative, maybe a (debconf or other) dialog to inform about issue and allow to abort the upgrade via old prerm and/or new preinst would be sensible on armhf, to make users aware of the db_dump(all) need? Requiring a manual upgrade or dump+restore is fine, but letting people run into a situation where both is not possible anymore without restoring a backup of the whole OS image, is probably not?
Just leaving this as a thought, in case if more bug reports like this pop up. Maybe most Debian users figure it out by themselves.
Among our ~140.000 users, mostly but not only SBCs, even that we do all we can to have users on 64-bit userland where possible, we still have ~15% 32-bit systems, mostly older Raspberry Pi models, and some Odroids.It's a valid option to keep using bookworm on old systems.
In individual cases sure, until it is EOL at least. But I would never recommend to others to stay on an older distro version just because the migration for PostgreSQL requires some extra steps, and won't start to provide Bookworm images, which just means that those need to do the upgrade anyway e.g. next year (Bookworm EOL).
This was just to show that there is still a significant amount of 32-bit ARM hardware around, which works perfectly fine with recent Linux and recent Debian, and does have use cases to not just bin them for new hardware. I just want to argue against "its your own problem if using 32-bit hardware" like thinking, as it IMO still has its place and its unique issues should IMO not be ignored, until Debian really drops 32-bit architectures from the repo. But I understand that there are limits to what can be reasonably handled by package maintainers.
Best regards, Micha
OpenPGP_0x0442B9ADE65643FE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
