On 05/09/2011 12:06 PM, Andrew Dunstan wrote:
> The fact that we can do in place upgrades of the data only addresses
> one pain point in upgrading. Large legacy apps require large retesting
> efforts when upgrading, often followed by lots more work renovating
> the code for backwards incompatibilities. This can be a huge cost for
> what the suits see as little apparent gain, and making them do it more
> frequently in order to stay current will not win us any friends.
I just had a "why a new install on 8.3?" conversation today, and it was
all about the application developer not wanting to do QA all over again
for a later release.
Right now, one of the major drivers for "why upgrade?" has been the
performance improvements in 8.3, relative to any older version. The
main things pushing happy 8.3 sites to 8.4 or 9.0 that I see are either
VACUUM issues (improved with partial vacuum in 8.4) or wanting real-time
replication (9.0). I predict many sites that don't want either are
likely to sit on 8.3 for a really long time. The community won't be
able to offer a compelling reason why smaller sites in particular should
go through the QA an upgrade requires. The fact that the app QA time is
now the main driver--not the dump and reload time--is good, because it
makes it does make it easier for the people with the biggest data sets
to move. They're the ones that need the newer versions the most anyway,
and in that regard having in-place upgrade start showing up as of 8.3
was really just in time.
I think 8.3 is going to be one of those releases like 7.4, where people
just keep running it forever. At least shortening the upgrade path has
made that concern a little bit better.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
