Summary Fedora 43 jumped system PostgreSQL from 16 ==> 18, but postgresql-upgrade only provides the previous major (17) under /usr/lib64/pgsql/postgresql-17. Users on 16 cannot run pg_upgrade because the required 16 binaries are absent. This forces workarounds (manual RPM extraction or container dump/restore) on a distro-driven major upgrade. Actual behavior F42 ships PG16; upgrade to F43 removes PG16. This makes pg_upgrade -b /usr/lib64/pgsql/postgresql-16/bin -B /usr/bin … function again without forcing users into dump/restore. dnf install postgresql-upgrade on F43 provides only /usr/lib64/pgsql/postgresql-17. Running pg_upgrade 16→18 fails due to missing 16 toolchain (and checksum/locale mismatches compound confusion). Expected behavior When Fedora skips a major (N=>N+2), users must still have a first-class, supported path to pg_upgrade. Proposed fix When Fedora skips a PostgreSQL major (e.g. 16 => 18), postgresql-upgrade must include the older major’s binaries (here: 16) so that pg_upgrade continues to work. i.e. for Fedora 43, postgresql-upgrade should provide: /usr/lib64/pgsql/postgresql-16/ Reproducible: Always Additional Information: Fedora 42 ==> 43 upgrades that were on PostgreSQL 16 do not have the needed 16 binaries present in Fedora 43. Users can recreate them by: 1. sudo mkdir -p /usr/lib64/pgsql/postgresql-16 2. sudo mkdir -p /tmp/pg16rpms 3. sudo dnf5 download --releasever=42 --disablerepo='*' --enablerepo=fedora,updates --destdir /tmp/pg16rpms postgresql16 postgresql16-server postgresql-libs postgresql-private-libs --arch=x86_64 4. cd /usr/lib64/pgsql/postgresql-16 5. for f in /tmp/pg16rpms/*.rpm; do sudo rpm2cpio "$f" | sudo cpio -idmv; done 6. sudo rsync -a usr/ . && sudo rm -rf usr 7. /usr/lib64/pgsql/postgresql-16/bin/postgres --version