Bug 1018522 - User not prompted to upgrade Postgres after upgrade from F19 to F20
User not prompted to upgrade Postgres after upgrade from F19 to F20
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Pavel Raiskup
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-12 17:51 EDT by Rob Sharp
Modified: 2013-10-15 16:11 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-13 13:55:01 EDT
Type: Bug
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 Rob Sharp 2013-10-12 17:51:23 EDT
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.
Comment 1 Pavel Raiskup 2013-10-13 13:55:01 EDT
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
Comment 2 Rob Sharp 2013-10-15 06:24:25 EDT
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
Comment 3 Pavel Raiskup 2013-10-15 06:44:10 EDT
> 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?
Comment 4 Pavel Raiskup 2013-10-15 06:47:06 EDT
> This issue is nothing which does not hurt us

s/is nothing/is not a problem/ :)
Comment 5 Will Woods 2013-10-15 14:58:38 EDT
(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.)
Comment 6 Tom Lane 2013-10-15 16:11:08 EDT
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.

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