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
Lots of folks are hitting this. ;( Adding commonbugs to whiteboard. You should be able to work around things by something like: % sudo dnf install postgresql17-server postgresql17-upgrade --allowerasing (this will replace postgresql package that is version 18) % sudo -u postgres postgresql-upgrade /var/lib/pgsql/data If you then want to move on to 18: % systemctl stop postgresql % sudo -u postgres pg_checksums -D /var/lib/pgsql/data -e -P (18 defaults to checksums on, you need to have them before you can upgrade) % sudo dnf install postgresql-server postgresql-upgrade --allowerasing % sudo -u postgres postgresql-upgrade /var/lib/pgsql/data (untested, please backup your database before trying)
Yes, this is one option to migrate to 17 and then to 18. I will try to find a more suitable solution.
https://tso.bzb.us/2025/11/postgresql-upgrade-fedora-42.html The above link gives full instructions.
(In reply to Kevin Fenzi from comment #1) > % systemctl stop postgresql > % sudo -u postgres pg_checksums -D /var/lib/pgsql/data -e -P > (18 defaults to checksums on, you need to have them before you can upgrade) > % sudo dnf install postgresql-server postgresql-upgrade --allowerasing > % sudo -u postgres postgresql-upgrade /var/lib/pgsql/data Something like this might better than enabling checksums, especially for large databases or if the file system already performs checksumming: # PGSETUP_INITDB_OPTIONS=--no-data-checksums postgresql-setup --upgrade
Thank you very much for your help. Anyway this does not work, when you create another database in a different directory like '/mnt/raider/datastore/postgres'. I was able to perform a sudo -u postgres postgresql-upgrade '/mnt/raider/datastore/postgres' but after a reboot the systemd fails with the message: Dez 26 17:22:09 chasmash postgresql-check-db-dir[1024]: An old version of the database format was found. Dez 26 17:22:09 chasmash postgresql-check-db-dir[1024]: Use 'postgresql-setup --upgrade' to upgrade to version '17'
Please ignore my previous comment, it was my fault! As a intermediate solution you may try to downgrade to postgresql16.
(In reply to Gerald Cox from comment #3) > https://tso.bzb.us/2025/11/postgresql-upgrade-fedora-42.html > The above link gives full instructions. This instructions doesn't work for me, because package postgresql-upgrade only contains binaries for PostgreSQL 17, but not for 16. There is no directory /usr/lib64/pgsql/postgresql-16/bin/ that is used in step 6 of the instruction. Installing postgresql17-upgrade doesn't work together with postgresql 18, because of missing dependencies. Installing postgresql17* packages also doesn't work for me, because I got errors about missing loadable libraries for postgresql. The postgresql log refers to another log file, but this doesn't exist.
(In reply to Edgar Hoch from comment #7) > (In reply to Gerald Cox from comment #3) > > https://tso.bzb.us/2025/11/postgresql-upgrade-fedora-42.html > > The above link gives full instructions. > > This instructions doesn't work for me, because package postgresql-upgrade > only contains binaries for PostgreSQL 17, but not for 16. There is no > directory /usr/lib64/pgsql/postgresql-16/bin/ that is used in step 6 of the > instruction. > > Installing postgresql17-upgrade doesn't work together with postgresql 18, > because of missing dependencies. > > Installing postgresql17* packages also doesn't work for me, because I got > errors about missing loadable libraries for postgresql. The postgresql log > refers to another log file, but this doesn't exist. Did you read the bug summary?
(In reply to Gerald Cox from comment #8) > Did you read the bug summary? I have read this bug, and the page with the instructions. And I have checked the common bugs, but didn't find an entry about this problem. And „F43 Change Proposal: PostgreSQL 18 (self contained)“, and Quick Docs PostgreSQL. Which bug summary do you mean? I didn't try to get the Fedora 42 packages for postgresql 16 on Fedora 43 as described in the description on this bug report, because there is a package postgresql17-upgrade which contains the binaries for postgresql 16 for upgrade. Maybe I should try it anyway, replacing the files from postgresql17-upgrade? I have tried to upgrade from 16 to 17 using postgresql17-upgrade, but this failed with message in file /var/lib/pgsql/upgrade_postgresql.log (sorry, some messages are in German): Zieldatenbanken: Datenbank: »template1« relname: »pg_catalog.pg_largeobject«, reloid: 2613, reltblspace: »« relname: »pg_catalog.pg_largeobject_loid_pn_index«, reloid: 2683, reltblspace: »« Datenbank: »postgres« relname: »pg_catalog.pg_largeobject«, reloid: 2613, reltblspace: »« relname: »pg_catalog.pg_largeobject_loid_pn_index«, reloid: 2683, reltblspace: »« führe aus: SELECT pg_catalog.set_config('search_path', '', false); Checking for presence of required libraries fatal Ihre Installation verweist auf ladbare Bibliotheken, die in der neuen Installation fehlen. Sie können diese Bibliotheken zur neuen Installation hinzufügen oder die Funktionen in der alten Installation entfernen. Eine Liste der problematischen Bibliotheken ist in der Datei: /fs/datenbanken7/postgresql/18/pg_upgrade_output.d/20251227T232010.564/loadable_libraries.txt Fehlgeschlagen, Programm wird beendet "/usr/bin/pg_ctl" -w -D "/fs/datenbanken7/postgresql/18" -o "" -m fast stop >> "/fs/datenbanken7/postgresql/18/pg_upgrade_output.d/20251227T232010.564/log/pg_upgrade_server.log" 2>&1 The file /fs/datenbanken7/postgresql/18/pg_upgrade_output.d/20251227T232010.564/loadable_libraries.txt doesn't exists, so I cannot check which loadable libraries are missing. pg_upgrade did something, but I'm not sure if it has already finished, and whether the error message ("Failed") at the end of the file has effects to the database data. On one database server, I did install postgresql16* on Fedora 43, started it on the database files of PostgreSQL 16, run pg_dumpall, removed packages postgresql16* and installed postgresql* (18), initialized an new PostgreSQL 18 database, and installed the data from the pg_dumpall file. But this was a smaller database instance. We have more database servers, one database is bigger, it will last longer (hours, days?) for dumping and reinstalling the database. Because the other server still runs Fedora 42, I consider to install the postgresql17* packages and upgrade the datebase to PostgreSQL 17, the install Fedora 43, and do the last step upgrading 17 -> 18 on Fedora 43. Additionally, I'm running pg_dumpall on this server, but it still will run more hours, I think.
(In reply to Edgar Hoch from comment #9) > (In reply to Gerald Cox from comment #8) > > Did you read the bug summary? > > I have read this bug, and the page with the instructions. And I have checked > the common bugs, but didn't find an entry about this problem. And „F43 > Change Proposal: PostgreSQL 18 (self contained)“, and Quick Docs PostgreSQL. > > Which bug summary do you mean? ... The “bug summary” refers to the Summary section at the top of this bug report. The behavior you are seeing (missing PG16 binaries, missing loadable libraries, pg_upgrade failures when mixing 16/17/18) is exactly what this bug describes. There is no supported in-place pg_upgrade path on Fedora 43 for systems upgraded from Fedora 42 that were running PostgreSQL 16. Users must either perform a dump/restore, or manually recreate the PostgreSQL 16 toolchain (as described above) to work around the missing binaries that Fedora 43 should have provided.
(In reply to Gerald Cox from comment #10) > The “bug summary” refers to the Summary section at the top of this bug > report. Oh, yes, of course I did see it. > There is no supported in-place pg_upgrade path on Fedora 43 for systems > upgraded > from Fedora 42 that were running PostgreSQL 16. Yes, I saw it. But this is not unrepairable. Fedora could provide the packages that are necessary for a working PostgreSQL 17 instance, then a upgrade could be done 16 -> 17 and then 17 -> 18. The missing packages could go to updates repository. I think this would help at least some not so experienced users, also with some delay after the Fedora release. For the future, it would be better not to stay so many Fedora versions on the same PostgreSQL version (here: 16), but upgrade earlier to prevent more than one PostgreSQL mayor release step! Fedora 42 should have gone to postgresql* package with version 17.*, and provide postgresql16* packages as a (working) alternative. Thanks in advance!
(In reply to Edgar Hoch from comment #11) > (In reply to Gerald Cox from comment #10) > > The “bug summary” refers to the Summary section at the top of this bug > > report. > > Oh, yes, of course I did see it. > > > There is no supported in-place pg_upgrade path on Fedora 43 for systems > > upgraded > > from Fedora 42 that were running PostgreSQL 16. > > Yes, I saw it. But this is not unrepairable. Fedora could provide the > packages that are necessary for a working PostgreSQL 17 instance, then a > upgrade could be done 16 -> 17 and then 17 -> 18. The missing packages could > go to updates repository. I think this would help at least some not so > experienced users, also with some delay after the Fedora release. > > For the future, it would be better not to stay so many Fedora versions on > the same PostgreSQL version (here: 16), but upgrade earlier to prevent more > than one PostgreSQL mayor release step! Fedora 42 should have gone to > postgresql* package with version 17.*, and provide postgresql16* packages as > a (working) alternative. > > Thanks in advance! PostgreSQL does not require stepping through every major version. A direct 16 to 18 upgrade via pg_upgrade is supported and works correctly as long as the PostgreSQL 16 and 18 binaries are present. The issue here is solely that Fedora 43 does not ship the required PostgreSQL 16 toolchain. That is why I created this bug report and documented the workaround.
Thanks for making this clear! I will try using your instructions for getting the postgresql 16 packages from Fedora 42, when I upgrade our next database server. https://www.postgresql.org/docs/18/pgupgrade.html describes „upgraded to a later PostgreSQL major version“ and gives examples with successive major numbers. Also some web pages tell that pg_upgrade only support upgrading to the next major version. But at the end of the page, in the Usage sections, they give an example of 12 -> 18. So, yes, the problem are the missing previous postgresql binaries and libraries. Fedora 43 should provide them both for postgresql 16 and 17, for example in package postgresql-upgrade, because databases from Fedora 41 and 42 may be on version 16 or 17. It may be, but I'm unsure, if postgresql extensions like postgis etc. must also be provided in an earlier version.
The process I outlined in https://bugzilla.redhat.com/show_bug.cgi?id=2411778#c1 should work from a upgraded f43 system. It definitely did here. Sounds like: > Installing postgresql17-upgrade doesn't work together with postgresql 18, because of missing dependencies. You might have missed this step: % sudo dnf install postgresql17-server postgresql17-upgrade --allowerasing (The allowerasing there is needed so it removes 18) which should leave you without any 18 installed, only 17. postgresql17-upgrade does have the 16 binaries.
I have new installed Fedora 43 systems (upgrades from previous needs to many manual work after the upgrade). The PostgreSQL database are on another disk on the system, which previously run with Fedora 42 and PostgreSQL 16. I have created a copy for upgrading to version 18. Calling „dnf install postgresql17-server postgresql17-upgrade --allowerasing“ as root (or with sodo) tells me „Nothing to do.“: # LANG=C dnf install postgresql17-server postgresql17-upgrade --allowerasing Updating and loading repositories: Repositories loaded. Nothing to do. # rpm -qa postgresql\* postgresql-private-libs-18.1-1.fc43.x86_64 postgresql-18.1-1.fc43.x86_64 postgresql-server-18.1-1.fc43.x86_64 postgresql-ip4r-2.4.2-7.fc43.x86_64 postgresql-upgrade-18.1-1.fc43.x86_64 postgresql-contrib-18.1-1.fc43.x86_64 But I had first removed these packages and then installed postgresql17* packages. Maybe that something like postgis is used the database, the data are from other users, I don't know the details. The upgrade failed after the following line in /var/lib/pgsql/upgrade_postgresql.log: Checking for presence of required libraries fatal
Odd. the postgresql17 packages are definitely in the base f43 repo. What does 'dnf list postgresql17\*' show? Do you have any dnf excludes set?
I have the following excludes (in /etc/dnf/repos.override.d/*): [fedora-multimedia] excludepkgs="*nvidia*" includepkgs="cuda*,libcu*,libnpp*,libnv*" [rpmfusion*] excludepkgs="*nvidia*,*cuda*" But I think these doesn't match the postgresql packages. # LANG=C dnf list postgresql17\* Updating and loading repositories: Repositories loaded. Available packages postgresql17.i686 17.6-1.fc43 fedora postgresql17.x86_64 17.6-1.fc43 fedora postgresql17-contrib.x86_64 17.6-1.fc43 fedora postgresql17-docs.x86_64 17.6-1.fc43 fedora postgresql17-plperl.x86_64 17.6-1.fc43 fedora postgresql17-plpython3.x86_64 17.6-1.fc43 fedora postgresql17-pltcl.x86_64 17.6-1.fc43 fedora postgresql17-private-devel.i686 17.6-1.fc43 fedora postgresql17-private-devel.x86_64 17.6-1.fc43 fedora postgresql17-private-libs.i686 17.6-1.fc43 fedora postgresql17-private-libs.x86_64 17.6-1.fc43 fedora postgresql17-server.i686 17.6-1.fc43 fedora postgresql17-server.x86_64 17.6-1.fc43 fedora postgresql17-server-devel.i686 17.6-1.fc43 fedora postgresql17-server-devel.x86_64 17.6-1.fc43 fedora postgresql17-static.i686 17.6-1.fc43 fedora postgresql17-static.x86_64 17.6-1.fc43 fedora postgresql17-test.x86_64 17.6-1.fc43 fedora postgresql17-test-rpm-macros.noarch 17.6-1.fc43 fedora postgresql17-upgrade.i686 17.6-1.fc43 fedora postgresql17-upgrade.x86_64 17.6-1.fc43 fedora postgresql17-upgrade-devel.i686 17.6-1.fc43 fedora postgresql17-upgrade-devel.x86_64 17.6-1.fc43 fedora
Additional info: I have the following options added in /etc/dnf/libdnf5.conf.d/20-ims.conf: [main] best=False skip_broken=True skip_unavailable=True installonly_limit=5 clean_requirements_on_remove=false I have tried "dnf install postgresql17-server postgresql17-upgrade --allowerasing --best" to negate the configuration "best=False", but it doesn't change the result. # LANG=C dnf install postgresql17-server postgresql17-upgrade --allowerasing --best Updating and loading repositories: Repositories loaded. Nothing to do. But wait: I thought about the other options, and tried # LANG=C dnf install postgresql17-server postgresql17-upgrade --allowerasing --best --setopt=skip_broken=false Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Removing dependent packages: pg_top x86_64 4.1.3-1.fc43 updates 106.3 KiB postgresql x86_64 18.1-1.fc43 updates 8.3 MiB postgresql-contrib x86_64 18.1-1.fc43 updates 3.6 MiB postgresql-private-libs x86_64 18.1-1.fc43 updates 372.0 KiB postgresql-server x86_64 18.1-1.fc43 updates 31.7 MiB postgresql-upgrade x86_64 18.1-1.fc43 updates 38.3 MiB Installing: postgresql17-server x86_64 17.6-1.fc43 fedora 30.8 MiB postgresql17-upgrade x86_64 17.6-1.fc43 fedora 36.8 MiB Installing dependencies: postgresql17 x86_64 17.6-1.fc43 fedora 7.9 MiB postgresql17-private-libs x86_64 17.6-1.fc43 fedora 343.6 KiB Transaction Summary: Installing: 4 packages Removing: 6 packages Total size of inbound packages is 18 MiB. Need to download 18 MiB. After this operation, 6 MiB will be freed (install 76 MiB, remove 82 MiB). Is this ok [y/N]: n Operation aborted by the user. I don't see no warning or note which package would be broken by the command, and was skipped? Maybe that pg_top and postgresql-contrib are not compatible with postgresql17* and had prevented the installation of postgresql17* ? Thank you for asking and for your efforts.
Additional note: # LANG=C dnf install postgresql17-server postgresql17-upgrade --allowerasing --setopt=skip_broken=false gives the same result, so the setting of option best doesn't matter. Is there a problem with dnf5? https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html#main-options describes option skip_broken this way: If enabled, DNF5 will skip uninstallable packages instead of failing while resolving dependencies. It seams, that skip_broken=true prevents removing dependent packages postgresql* ? But this should be allowed by option --allowerasing .
(In reply to Edgar Hoch from comment #18) > Additional info: > I have the following options added in /etc/dnf/libdnf5.conf.d/20-ims.conf: > > [main] > best=False > skip_broken=True > skip_unavailable=True > installonly_limit=5 > clean_requirements_on_remove=false > > > I have tried "dnf install postgresql17-server postgresql17-upgrade > --allowerasing --best" to negate the configuration "best=False", but it > doesn't change the result. > > # LANG=C dnf install postgresql17-server postgresql17-upgrade --allowerasing > --best > Updating and loading repositories: > Repositories loaded. > Nothing to do. > > > But wait: I thought about the other options, and tried > > # LANG=C dnf install postgresql17-server postgresql17-upgrade --allowerasing > --best --setopt=skip_broken=false > Updating and loading repositories: > Repositories loaded. > Package Arch Version > Repository Size > Removing dependent packages: > pg_top x86_64 4.1.3-1.fc43 > updates 106.3 KiB > postgresql x86_64 18.1-1.fc43 > updates 8.3 MiB > postgresql-contrib x86_64 18.1-1.fc43 > updates 3.6 MiB > postgresql-private-libs x86_64 18.1-1.fc43 > updates 372.0 KiB > postgresql-server x86_64 18.1-1.fc43 > updates 31.7 MiB > postgresql-upgrade x86_64 18.1-1.fc43 > updates 38.3 MiB > Installing: > postgresql17-server x86_64 17.6-1.fc43 > fedora 30.8 MiB > postgresql17-upgrade x86_64 17.6-1.fc43 > fedora 36.8 MiB > Installing dependencies: > postgresql17 x86_64 17.6-1.fc43 > fedora 7.9 MiB > postgresql17-private-libs x86_64 17.6-1.fc43 > fedora 343.6 KiB > > Transaction Summary: > Installing: 4 packages > Removing: 6 packages > > Total size of inbound packages is 18 MiB. Need to download 18 MiB. > After this operation, 6 MiB will be freed (install 76 MiB, remove 82 MiB). > Is this ok [y/N]: n > Operation aborted by the user. > > > I don't see no warning or note which package would be broken by the command, > and was skipped? > > Maybe that pg_top and postgresql-contrib are not compatible with > postgresql17* and had prevented the installation of postgresql17* ? > > Thank you for asking and for your efforts. You are right, postgresql-contrib is of version 18, you should better try to install postgresql17-contrib.
Adding postgresql17-contrib doesn't solve the problem with dnf. But it adds postgresql17-contrib to the packages that will be installed if ---setopt=skip_broken=false is used. # LANG=C dnf install postgresql17-server postgresql17-upgrade postgresql17-contrib --allowerasing Updating and loading repositories: Repositories loaded. Nothing to do. # LANG=C dnf install postgresql17* --allowerasing Updating and loading repositories: Repositories loaded. Nothing to do. # LANG=C dnf install postgresql17-server postgresql17-upgrade --allowerasing ---setopt=skip_broken=false Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Removing dependent packages: pg_top x86_64 4.1.3-1.fc43 updates 106.3 KiB postgresql x86_64 18.1-1.fc43 updates 8.3 MiB postgresql-contrib x86_64 18.1-1.fc43 updates 3.6 MiB postgresql-private-libs x86_64 18.1-1.fc43 updates 372.0 KiB postgresql-server x86_64 18.1-1.fc43 updates 31.7 MiB postgresql-upgrade x86_64 18.1-1.fc43 updates 38.3 MiB Installing: postgresql17-server x86_64 17.6-1.fc43 fedora 30.8 MiB postgresql17-upgrade x86_64 17.6-1.fc43 fedora 36.8 MiB Installing dependencies: postgresql17 x86_64 17.6-1.fc43 fedora 7.9 MiB postgresql17-private-libs x86_64 17.6-1.fc43 fedora 343.6 KiB Transaction Summary: Installing: 4 packages Removing: 6 packages Total size of inbound packages is 18 MiB. Need to download 18 MiB. After this operation, 6 MiB will be freed (install 76 MiB, remove 82 MiB). Is this ok [y/N]: n Operation aborted by the user.
I've prepared a build for Rawhide with the possibility of upgrading from PostgreSQL 16 to 18. https://bodhi.fedoraproject.org/updates/FEDORA-2026-6ab32469b7 Steps to use such an upgrade: # dnf install postgresql-upgrade $ export PGSETUP_INITDB_OPTIONS=--no-data-checksums $ postgresql-upgrade --upgrade-from postgresql16 /var/lib/pgsql/data If there is no issue with this change, I will also use the same approach for f43.