If you run on the Amazon cloud, it's tempting to use Amazon's own Linux distro. One might expect it to be built to run well on the platform, and also the updates will be close at hand and not incur any traffic charges. However, they seem to have made a major blunder in packaging PostgreSQL.
I found out about this when a very angry user came on the IRC channel yesterday. He had done a "yum update" and suddenly found that his database would not work. He shared the log with us, and here's a small excerpt from it:
---> Package postgresql9-server.x86_64 0:9.1.5-1.23.amzn1 will be obsoleted
---> Package postgresql9-upgrade.x86_64 0:9.2.1-1.28.amzn1 will be obsoleting
--> Processing Dependency: postgresql9-server(x86-64) = 9.2.1-1.28.amzn1 for package: postgresql9-upgrade-9.2.1-1.28.amzn1.x86_64
Wow. They are upgrading the postgres-server package from 9.1 to 9.2, on a simple "yum update". That is just awful. You don't get anything like that happening on any other RPM-based system I know of, certainly not on any RedHat or SUSE derived system I have ever seen. "yum update" should not be doing this sort of thing.
I suspect that it's happened because the Amazon packagers don't actually understand PostgreSQL version numbering. The have two collections of packages, one with "postgres8" and one with "postgres9" as the prefix. But as most (I hope) PostgreSQL users know, our major version numbers have two parts, not one, as can be seen in the versioning policy Upgrading to a new major version via a simple "yum update" is a totally bad thing to be doing.
Apparently it has caused enough problems for them to have issued an FAQ about it. But really, that's no answer. This is exactly the sort of thing you should NOT have to do after a simple "yum update". pg_upgrade is not guaranteed to work in all circumstances, and if it fails in one of the many ways it can fail, the user will be left scrambling.
What's really annoying about this is that users are just as likely to blame Postgres for this mess as they are to blame Amazon.
I don't know who to contact at Amazon to urge them to fix this mess, so I've written this in the hope it might help someone who encounters the problem. And for now I am going to advise customers and others to avoid using this. There are lots of other AMIs that can be used on Amazon. If you must use Amazon Linux, I suggest using the PostgreSQL community yum repos, although this probably requires a tiny bit of work to start with: see how I did this before we got support for ScientificLinux
I don't like PostgreSQL's versioning, and would love it if the team agreed to go to traditional major.minor.revision versioning instead of major.major2.revision . I see regular confusion about this on Stack Overflow, etc.<br />
That said, Amazon really should know better, as should anyone who's packaging PostgreSQL for anyone for any reason. This is dangerously stupid of them and shows amazing disregard for customers and their data.
Yes, you can. It's reasonable to expect someone who's packaging software for public consumption to get it right, especially when that software is documented comprehensively and the issue is explained on the website ( http://www.postgresql.org/support/versioning/ ).<br />
I dislike Pg's versioning, but it's just incompetent to package software that doesn't handle it properly.<br />
As for weird versioning: Sun/Oracle can't decide if Java is Java 1.7 or Java SE 7. Adobe has long had Acrobat x support format PDF x-1 (eg: Acrobat 5 supported up to PDF 1.4), but has more recently broken that with Acrobat X. Then there's Mac OS X 10.x for bonus point-release breakage. Or Windows 7 (actually version 6.1). For all that I dislike PostgreSQL's versioning, it's far from alone in having weird versioning.
I agree it's easy to get bitten by OS upgrades, it's happened to me before. But how is this different from a new major version of PostgreSQL being included in a new release of Ubuntu or Debian or whatever? The FAQ link specifically mentions differences between "2011.09" and "2012.03" releases.
Because it's NOT happening with an OS upgrade. It's happening on a plain "yum update". I guarantee you that this would not happen on any RedHat or SUSE system on a "yum update", which is a command you would run to pick up package updates which you should be able to expect will NOT break in this way (security updates, bug fixes and so on).