I don't want to hijack this thread any further, but Craig, thanks for your insight.
-Harold On Thu, Nov 7, 2013 at 8:35 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 11/08/2013 11:41 AM, Harold Giménez wrote: > > > > > > > > On Thu, Nov 7, 2013 at 7:01 PM, Craig Ringer <cr...@2ndquadrant.com > > <mailto:cr...@2ndquadrant.com>> wrote: > > > > > > (a) Lots of people only upgrade every two, three, or even more major > > versions. I'm dealing with clients on 8.3, and people still pop up on > > Stack Overflow with 8.1 sometimes! These people don't ever see the > > deprecated phase. > > > > > > Interesting that they'd never update their clients either. I guess if > > that's true > > there's a mentality of if it ain't broke don't fix it going on here. > > I've seen all sorts of combinations of client and server versions in the > wild. Ancient JDBC, ODBC, etc drivers are also common. > > > Would they read change logs before upgrading, or just cross their > fingers? > > > > (b) People routinely ignore cron job output. Even important job > output. > > They won't see the messages, and won't act on them if they do until > > something actually breaks. > > > > > > How common is this? > > I couldn't possibly say, I can only go by what I see in communication > with clients, in private mail, in the mailing lists, and on Stack Overflow. > > I do see a couple of different groups: > > * People who upgrade casually without looking at release notes etc, then > wonder why everything just broke. Typically people running PostgreSQL in > development environments. I'm not too fussed about this group, they do > it to themselves. On the other hand they're a *big* group (think Ruby on > Rails developers, etc) and the more of them who whine about how > PostgreSQL is painful to upgrade and always breaks, the worse it is for > general uptake of Pg. > > * Those who don't upgrade because they don't know or care to. That box > has been sitting there doing its thing for ages, and until they hit some > key limitation, trigger an old bug, or finally need to do something > different they don't realise that life would've been easier if they > hadn't stayed on 7.1. These folks seem to be the most likely ones to > unthinkingly upgrade from 7.something-low or 8.x straight to 9.3 without > reading the release notes then wonder why things don't work, especially > since they'll tend to do it in a hurry as a knee-jerk to try to fix a > problem. > > * People who want to upgrade but are choked by bureaucracy and change > management processes that move on a tectonic time scale. They're still > on 8.something-low because it's just too painful to change. They're the > ones who'll ask you to backport synchronous replication into 9.0 because > they're not allowed to upgrade to 9.1/9.2, despite the obvious insanity > of running custom-patched and rebuilt software instead of a well-tested > public release. When they upgrade they do it in giant leaps despite the > pain involved, just because it's so hard to upgrade at all. They're > likely to plan carefully and do it right. > > * People who'd love to upgrade, but have an old database running a 24x7 > mission critical system with enough data that they just can't get a > dump/reload window, and they're on something older than 8.4 so they > can't pg_upgrade. When they do upgrade they tend to plan it in detail, > test carefully first, etc, so again they're pretty OK. > > > In general, people are busy and the database isn't all they care about. > They probably read the release notes about as well as you read the > release notes on a new distro upgrade or something else that you care > moderately about. > > If you're doing a major upgrade from an old Pg to a very new one there's > a lot to take in and a lot of rel notes to read. One of the things that > might help here is if we had (on the wiki, maybe) a single document that > kept a running list of compatibility affecting changes and upgrades that > need special action, along with a recommended upgrade path. That way > people wouldn't have to read 6 major versions of release notes, get half > way, and give up. > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >