Re: Changing pg_dump default file format - Mailing list pgsql-hackers

On 11/08/2013 11:41 AM, Harold Giménez wrote:
>
>
>
> On Thu, Nov 7, 2013 at 7:01 PM, Craig Ringer <craig@2ndquadrant.com

> <mailto:craig@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