Description of problem: A fedup upgrade from F19 to F20 resulted in this user missing the prompt (if there is one) to also upgrade postgres. Version-Release number of selected component (if applicable): / ᐅ rpm -q postgresql postgresql-9.3.0-1.fc20.x86_64 How reproducible: I am unable to revert my system to its previous state to re-confirm. Steps to Reproduce: 1. Given an install of Fedora 19, with an installation of Postgres 9.2 2. Upgrade Fedora to F20, via fedup 3. Attempt to connect to Postgres Actual results: My webapp (Rails) failed to connect with a standard Rails error message. ~/Projects/sorbet (url_signing_spike ✘)✹✚ ᐅ rails s Warning: RMagick not installed, you cannot generate captcha images on this machine => Booting WEBrick => Rails 3.2.14 application starting in development on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server citier -> Root Class citier -> table_name -> products Exiting /home/robsharp/.rvm/gems/ruby-1.9.3-p194@ratecity/gems/activerecord-3.2.14/lib/active_record/connection_adapters/postgresql_adapter.rb:1222:in `initialize': could not connect to server: Connection refused (PG::Error) Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432? Expected results: I expected my Rails application to connect, given it had the correct configuration. Additional info: [root@laphroaig]/home/robsharp/Projects/sorbet# service postgresql status Redirecting to /bin/systemctl status postgresql.service postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled) Active: failed (Result: exit-code) since Sat 2013-10-12 22:49:02 EST; 1min 24s ago Process: 15763 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=1/FAILURE) Oct 12 22:49:02 laphroaig systemd[1]: Starting PostgreSQL database server... Oct 12 22:49:02 laphroaig postgresql-check-db-dir[15763]: An old version of the database format was found. Oct 12 22:49:02 laphroaig postgresql-check-db-dir[15763]: Use "postgresql-setup upgrade" to upgrade to version 9.3. Oct 12 22:49:02 laphroaig postgresql-check-db-dir[15763]: See /usr/share/doc/postgresql/README.rpm-dist for more ...ion. Oct 12 22:49:02 laphroaig systemd[1]: postgresql.service: control process exited, code=exited status=1 Oct 12 22:49:02 laphroaig systemd[1]: Failed to start PostgreSQL database server. Oct 12 22:49:02 laphroaig systemd[1]: Unit postgresql.service entered failed state. Oct 12 22:49:58 laphroaig systemd[1]: Stopped PostgreSQL database server. Hint: Some lines were ellipsized, use -l to show in full. [Installed and ran the postgresql-setup upgrade package] [root@laphroaig]/home/robsharp/Projects/sorbet# service postgresql status Redirecting to /bin/systemctl status postgresql.service postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled) Active: active (running) since Sat 2013-10-12 22:50:34 EST; 2s ago Process: 16275 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p ${PGPORT} -w -t 300 (code=exited, status=0/SUCCESS) Process: 16268 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS) Main PID: 16278 (postgres) CGroup: /system.slice/postgresql.service ├─16278 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432 ├─16279 postgres: logger process ├─16281 postgres: checkpointer process ├─16282 postgres: writer process ├─16283 postgres: wal writer process ├─16284 postgres: autovacuum launcher process └─16285 postgres: stats collector process Oct 12 22:50:33 laphroaig pg_ctl[16275]: LOG: redirecting log output to logging collector process Oct 12 22:50:33 laphroaig pg_ctl[16275]: HINT: Future log output will appear in directory "pg_log". Oct 12 22:50:34 laphroaig systemd[1]: Started PostgreSQL database server.
Thanks for this report, Rob. I expect that everything is OK after database upgrade, yes? I don't think there can be done more that just in fedup add some "note" that user should (after full reboot) do 'postgresql-setup upgrade'. As I'm not aware of any "plug-in" capability of fedup, this would have to be done directly in package fedup. Really, this would be more like a "content" adjusting for some versions of Fedora which just duplicates the work, because the way you were instructed to run 'postgresql-setup upgrade' is IMO straight forward and IMO very valid. For me this is NOTABUG. But feel free to reopen if you see that we may do something in PostgreSQL or reopen against fedup, if you feel there should be some note. Pavel
Hi Pavel, Yes - everything was fine after the upgrade. I thought I'd bring this to your attention but, if you believe everything is as it should be, I'm fine with that! - Rob
> I thought I'd bring this to your attention but, [...] Thanks for bringing it this way once again - it will be burned in bugzilla forever so anybody may start from this point in future. This issue is nothing which does not hurt us, but the database upgrade process is not very easy for full automation. And "in-place" upgrade of Fedora is definitely hard task right because problems like this one. I am adding maintainer of 'fedup' to CC, maybe he could point us some expected way for Feodra, Will? Is there a way (not considering %post* scriplets, it would be IMO non-maintainable) how to notify user that some action is required after Fedora upgrade?
> This issue is nothing which does not hurt us s/is nothing/is not a problem/ :)
(In reply to Pavel Raiskup from comment #3) > I am adding maintainer of 'fedup' to CC, maybe he could point us some > expected > way for Feodra, Will? Is there a way (not considering %post* scriplets, it > would be IMO non-maintainable) how to notify user that some action is > required > after Fedora upgrade? Anything that can be done *automatically* for *all users* should be done in a package %post/%posttrans script. Anything that requires user interaction to decide what to do.. should be handled by some other pre- or post-upgrade service. (No such service exists yet, though.)
FWIW, our historical position on this has been that an *automatic* major-version upgrade would be a seriously bad idea. Postgres major version updates usually involve some amount of client-visible incompatibilities, which a user might not want to deal with right away during an OS upgrade. In the past, the way was open to install a self-compiled previous-version server and keep using that until you were ready for the PG server upgrade. If we automatically upgrade the database during the OS upgrade then such a user is out of luck. There's no upstream support for reversing a database storage upgrade, and I doubt it'd work reliably.