The upgrade process of postgresql is a bit of a pain, and unfortunately a RPM packaging of it only makes it worse. The problem is that postgresql requires the following at an upgrade: 1. Dump the database 2. Upgrade PostgreSQL 3. Init a fresh database 4. Restore the dump This means that if you upgrade the packages on your system, and the postgresql is in that set, you perform step 2 in this process without having done step 1. At this point you're screwed, as the new tools won't let you dump the old database. So the package really needs to incorporate some scripts to handle this. That, or make sure yum refuses to upgrade postgresql by default.
*** Bug 460074 has been marked as a duplicate of this bug. ***
Allowing quiet rpm upgrades like this, when it is known that databases will be broken, is tantamount to punishing your installed base. Please consider just not pushing further updates until a more satisfactory solution is available, or at least add a rpm scriptlet to block updates if attempted.
Wouldn't a scriptlet-produced failure result in failure of the entire OS update? I'm worried about a scenario where the update involves replacing package foo.N with foo.N+1, and the old version of postgres depends on foo.N and the new on foo.N+1. This might be workable anyway on RHEL, where we try to provide binary compatibility packages for most values of foo, but I don't think it'd be a useful answer for Fedora.
> Wouldn't a scriptlet-produced failure result in failure of the entire OS > update? I'm not sure. If so, then it is even more important to find a proper solution. A few more ideas: - teach dumpdb pronto to read old formats - if upstream can't be bothered, then find a way of building & including older dumpdb binaries in an updated postgresql; or maybe a new "postgresql-compat-dumpdb" rpm - add a %preun scriptlet that dumps old databases during an update, so that the sysadmin can manually restore them later; space permitting
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Nothing has happened here so I'm moving it up to rawhide.
I blew my foot of again with this, so if we could please find a way to handle this. Or at the very least refuse to upgrade the package when it will make the database inaccessible.
*** Bug 542822 has been marked as a duplicate of this bug. ***
Tom Lane, on duplicated bug, post #1: > ... What you > need to do to update your data is pg_dumpall in the old installation and load > the data into the new one. It's not something that's easily solved at the > packaging level, unfortunately. Yes, unfortunately it's not so easy to do at packaging level. But I agree with Frank suggestion above. The hard step is to dump de database with an old PostgreSQL installation, because you have a updated installation. So I think some script that dumps the database before de update, as a 'dumped_db.rpmsave', would be a great improvement on this issue.
Whooops guys, you did it again. On FC11 => FC12. Is any body going to do something about this sometimes? Blowing up a DBMS IS serious stuff, after all...
Try "service postgresql upgrade" with 9.0.2, just pushed to rawhide.
I just tried this after an f14->f15 upgrade. The good news: it did work in the end The bad news: 1. there was not the slightest hint anywhere why the f15 pg-server was failing to start 2. the upgrade didn't work at first because I didn't have "trust" in my pg_hba.conf. I fixed that and then it ran. But: the "new" pg_hba.conf was a fresh copy after the upgrade. My customizations had been wiped away.
(In reply to comment #12) > 1. there was not the slightest hint anywhere why the f15 pg-server was failing > to start Yeah :-(. There's not much I can do about that in F15, because systemd's handling of sysv initscripts is so completely sucky (cf bug #622663, and note the utter lack of action on that). F16 should be better, because I bit the bullet and moved postgres to native systemd start scripts, but I can't put that into F15. > But: the "new" pg_hba.conf was a > fresh copy after the upgrade. My customizations had been wiped away. Yeah, that's expected. The new version doesn't necessarily have the same settings the old one did, and pg_upgrade is not smart enough to try to transpose whatever customizations you did. Your old configuration files should be in /var/lib/pgsql/data-old/ for reference, though.
(In reply to comment #13) > F16 should be better, because I bit the > bullet and moved postgres to native systemd start scripts, How should this work in F16? I'm trying service postgresql upgrade but this is the result: Redirecting to /bin/systemctl upgrade postgresql.service Unknown operation upgrade
(In reply to comment #14) > How should this work in F16? I'm trying > service postgresql upgrade systemd doesn't support custom action keywords, unfortunately. See the package's README or here: http://fedoraproject.org/wiki/Docs/Beats/DatabaseServers
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I see no reason to keep this open, or? Closing as CURRENTRELEASE, anybody: feel free to reopen if you see some reason, thanks!