Bug 398221 - upgrade makes database unusable
upgrade makes database unusable
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Pavel Raiskup
Fedora Extras Quality Assurance
: FutureFeature
: 460074 542822 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-25 04:57 EST by Pierre Ossman
Modified: 2013-06-14 10:26 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-14 10:26:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pierre Ossman 2007-11-25 04:57:23 EST
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.
Comment 1 Tom Lane 2008-08-25 22:51:48 EDT
*** Bug 460074 has been marked as a duplicate of this bug. ***
Comment 2 Frank Ch. Eigler 2008-08-25 23:04:26 EDT
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.
Comment 3 Tom Lane 2008-08-25 23:47:05 EDT
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.
Comment 4 Frank Ch. Eigler 2008-08-26 07:41:56 EDT
> 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
Comment 5 Bug Zapper 2008-11-26 03:40:52 EST
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
Comment 6 Pierre Ossman 2008-11-28 08:20:48 EST
Nothing has happened here so I'm moving it up to rawhide.
Comment 7 Pierre Ossman 2009-02-08 16:28:42 EST
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.
Comment 8 Tom Lane 2009-11-30 19:21:29 EST
*** Bug 542822 has been marked as a duplicate of this bug. ***
Comment 9 Bruno Medeiros 2009-12-10 20:56:13 EST
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.
Comment 10 alien_life_form 2010-06-16 12:54:31 EDT
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...
Comment 11 Tom Lane 2010-12-28 19:37:35 EST
Try "service postgresql upgrade" with 9.0.2, just pushed to rawhide.
Comment 12 Sven Lankes 2011-09-04 15:24:50 EDT
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.
Comment 13 Tom Lane 2011-09-04 16:57:37 EDT
(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.
Comment 14 Murray Cumming 2011-10-10 18:14:01 EDT
(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
Comment 15 Tom Lane 2011-10-10 19:32:13 EDT
(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
Comment 16 Fedora Admin XMLRPC Client 2013-05-09 10:06:44 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 17 Fedora Admin XMLRPC Client 2013-05-16 05:58:31 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 18 Pavel Raiskup 2013-06-14 10:26:42 EDT
I see no reason to keep this open, or?  Closing as CURRENTRELEASE,
anybody:  feel free to reopen if you see some reason, thanks!

Note You need to log in before you can comment on or make changes to this bug.