Apparently this is not possible though. So what? Was the changeset proposal sold with how easy it was to upgrade, even though knowing that it wouldn’t work?
Don’t get me wrong, I can certainly upgrade the postgres databse from 16 to 18.
But the way Fedora handled this is not ok. Telling people that an upgrade is easy by just issuing one command, while in reality people have to manually upgrade, is not very trustworthy.
Also, if an upgrade has to be done manually, this should be noted in the documentation.
So both the changeset and the documentation are wrong. You did not even tell people to install postgres 17 on f42 first.
Otherwise people have to dump and recreate all databases. This is not a one command process.
Speaking for myself as a FESCo member: If the Change owner writes in the Change proposal that upgrading from postgresql 16 to 18 is just “run this command” that’s something I trust them to know and assume to be correct - I don’t think we can (or should) fact-check everything that is in Change proposals. (Personally, I wasn’t even aware that PostgreSQL didn’t support skipping versions when migrating databases …) That said - I think it’s clear that the update to PostgreSQL 18 for Fedora 43 wasn’t handled the way it should have been. I’m not sure how we could have prevented this issue from happening, but I think we’d be open to suggestions
Issues like this one are also something that is often just caught after release - because that’s when users who don’t want to run beta software upgrade their systems. So it’s kind of the “late early adopter tax” because it’s hard to catch everything during pre-relase testing and release validation. But that doesn’t mean that the documentation can’t be improved now … at least to me, it looks like the Quick Docs were written under the assumption that upgrading Fedora never causes a PostgreSQL version to be skipped (like v16 → v18 on upgrade from Fedora 42 → 43).
Unfortunately there are a few issues. Fedora does not allow to install multiple versions of Postgres, which makes this a bit more complicated. Luckily the postgres-upgrade packages include the “old” (n-1) binaries.
There are a few options available how to do the upgrade. I am trying to find a nice solution that is the least error prone.
e.g. if you are not careful you might end up with things like old cluster does not use data checksums but the new one does.
An upgrade always replaces your config files with the default ones.
The easiest solution for non-database experts is probably
remove postgres 18
install postgres 17
run the upgrade
adjust and or consolidate config files from old and new data dir
update collation for all databases
remove postgres 17
install postgres 18 again
run the upgrade
adjust and or consolidate config files from old and new data dir
update collation for all databases
For database experts, a manual pg_dump / pg_dumpall might be a better option.
Or one could install the postgres17-upgrade package (which has the v16 binaries) and run the db_upgrade binary (which is the v17) from the postgres18-upgrade package.
And then another pg_upgrade from the postgres18-server package.
Usually a db admin knows how to go about those things. I am just saying that someone who just installs postgres because it is needed by some other package might be overwhelmed, after upgrading to Fedora 43. Because all of a sudden their database server won’t start and they can’t just do a simple upgrade as described in the docs.
I am a bit fuzzy on that. Did no one actually test this? e.g. upgrade from f42 to f43 and ty to use their postgres database? This seems extremely strange to me.
Or one could install the postgres17-upgrade package (which has the v16 binaries) and run the db_upgrade binary (which is the v17) from the postgres18-upgrade package.
And then another pg_upgrade from the postgres18-server package.
Scratch that. This does not work, because certain binaries are missing which are required for an upgrade, e.g initdb.
Additionally dnf does not let you install it anyway. One would have to use rpm and force install.
And pg_dump and pg_dumpall would have had to be run on postgres 16, so as soon as someone upgrades to f43, they are screwed unless they remove postgres 18.
So. people have 2 choices:
install postgres 17 on f42 and upgrade before upgrading to f43
if already on f43, remove postgres 18 and install postgres 17, upgrade, install postgres 18, upgrade
I think this is likely - and not necessarily strange. We can’t test all 25000 packages in Fedora whether they work correctly on both fresh installs an on upgrade. There are defined (but limited) test matrices that determine whether a new Fedora release is ready or not (linked here for the final RC that was shipped as Fedora 43):
And it appears that “upgrade from Fedora N-1 and migrate your postgres database” is not included, though some other PostgreSQL tests are:
Arguably this might be an oversight, and it might be a good idea to include this scenario in what’s supposed to get tested before a release is declared “ready”.
I am not asking anyone to test 25000 packages, but at least the 35 that are in the changeset for a release.
Once again, this is not about me. I can pretty much recover from anything, but I am talking about a Fedora user that might have come from Windows and after the 2nd OS upgrade is stuck in a cannot-upgrade-the-database-but-needs-it-urgently situation.
@decathorpe next time I’m in Austria, let’s grab a beer…
Surely the Change Owner is expected to test the upgrade instructions in the Change Proposal before submitting the proposal?
Of course that’s not foolproof - in general, a procedure that works on some systems won’t work on all of them - but in this case it seems like the documented procedure would fail for any upgrade from F42 / postgres 16 to F43 / postgres 18.
Feedback was given here that it would have been wise to move to postgres 17 in F43 rather than jumping to 18. Was this considered when deciding whether to approve the change?
I hate writing docs as much as the next person, but after having been in management for the past 8 years or so, I have been writing docs for my team when they are busy with coding and whatnot.
Thus give me a few days and I’ll write up a document (in markdown) how to migrate from p16 to p18 before and/or after moving to f43. Or let the doc guys ping me, if they don’t need any help. I rather not waste my time, if nobody’s gonna use my help document anyway.
I encountered an additional complication while trying to upgrade my postgres 16 database to 17 with postgresql-setup upgrade after uninstalling postgres 18 and installing postgresql17-upgrade: the upgrade fails due to a missing library.
Your installation references loadable libraries that are missing from the
new installation. You can add these libraries to the new installation,
or remove the functions using them from the old installation. A list of
problem libraries is in the file:
/var/lib/pgsql/data/pg_upgrade_output.d/20251031T113253.585/loadable_libraries.txt
Unfortunately I can’t find the referenced loadable_libraries.txt file in that folder or on my filesystem to check what the problem library is. The folder /var/lib/pgsql/data/pg_upgrade_output.d doesn’t exist after running postgresql-setup upgrade. I suspect it’s going to be because of pgvector, which I was using in postgres 16.
However, while Fedora 43 appears to have a pgvector package for postgres 18 and has postgresql16-pgvector for postgres 16, I’ve been unable to find an equivalent for postgres 17. Is it possible this package was forgotten to be included?
That’s an interesting situation. But the missing library should be referenced somewhere, maybe in the upgrade.log?
The more info, the better. I’ll add that to the upgrade doc when I start wriring it.
/var/lib/pgsql/upgrade_postgresql.log didn’t have more info besides the part I quoted, but I found out why the loaded_libraries.txt file is gone: it’s part of the “new” postgres data folder when upgrading, and the postgresql-setup script deletes that folder (/var/lib/pgsql/data) and puts the old pre-upgrade one back if a failure occurs. I’ll fiddle with it a bit to extract the log that gets deleted.
Update: it was because of pg_trgm, so not pgvector. Installing postgresql17-contrib fixed the error and I was able to upgrade. I had dropped all databases that were using pgvector, so that didn’t impact me, but I do still wonder how that dependency is supposed to be fulfilled in postgres 17.
